Realtime Divergence for Any Indicator - By John BartleThe main purpose of this script is to show historical and real-time divergences for any oscillating indicator. The secondary purpose is to give the user a lot of precise control over identifying divergences and determining what they are. This is an improved version of my other script which is similarly called "Realtime Divergence for Any Indicator"
There are four types of divergences that are offered:
Bull divergence
Hidden bull divergence
Bear divergence
Hidden Bear divergence
There are three types of potential(real-time) divergences which include:
1) Without right side bars for rightside pivots. Plus without waiting for the rightside pivot bar to complete
2) Without right side bars for rightside pivots. Plus with waiting for the rightside pivot bar to complete
3) With right side bars for rightside pivots. Plus without waiting for the rightside pivot right-most bar to complete
A definite divergence occurs when all specified bars are accounted for and fully formed.
Potential divergences use dashed lines and definite(historical) divergences use solid lines.
In addition to several other categories of settings to filter out unwanted divergences or manipulate the search process, this script also offers Alerts. Remember that alerts must not only be set within this scripts settings but also your "Alerts" panel on your right. It's strange but BOTH must be set for alerts to work...
Other interesting Things To Know:
1)I actually don't trade and so I have no need of a paid account. Unpaid accounts don't have the playback feature so I haven't really tested this script out very well. Sorry. Just let me know if something seems off and IF I have time I'll try to fix it.
2)Keep in mind that Pinescript limits the number of lines that can be shown at one time. This means that if your settings allow for a large number of divergence lines they will be removed from the leftward side of your chart but appear in the rightward side.
3) The time and the values for the price or oscillator are not the same things as each other nor are they physical things with physical space. This means that slopes of lines using the time as X and value as Y can not have definite angles. Consequently, under the setting "DIVERGENCES: SLOPE ANGLE EXCLUSION" YOU have to decide what slope equals what angle by using the setting called "Normalization Factor".
4) Remember that some individual settings apply to both the oscillator and price chart. This means that even if the setting's conditions are fulfilled in one they may not be fulfilled in the other.
5) Under the category "DIVERGENCES: INTERSECTION ALLOWANCE", if you set the "Measurement Type" to Relative Percentage then FYI any single given length will equate to an increasingly smaller percentage the further away from zero it is. Because of this, I think "Reletive Percentage" is probably only useful for price charts or oscillators with big values. Maybe >200 is OK ?
Errors:
1) If you get the error mentioning that the script must complete execution within X amount of time, this is because this is a big script and sometimes takes longer than your service plan's allotted time limit. You can just disable some of the settings to reduce the scripts amount of work and time. The biggest time savers will be to disable some lines and labels
2) If you get an error saying the script accessed a negative index(e.g. ) then try temporarily increasing the "Add More Array Elements" setting to 100-200. Sometimes it fixes the problem.
3) You may sometimes temporarily get an error that reads: "Pine cannot determine the referencing length of a series. Try using max_bars_back in the study or strategy function".
If this happens there are several things that you can do:
3A) Create a copy of my script. Then edit the section of code that looks like this ")//, max_bars_back = INSERT_YOUR_QUANTITY_HERE)" and transform it to look like this new code ", max_bars_back = INSERT_YOUR_QUANTITY_HERE)" then repeatedly try replacing "INSERT_YOUR_QUANTITY_HERE" with an increasingly larger number greater than 244 but less than 5000.
This method will increase your system resources and could cause other problems. Try changing the code back after a few hours and see if all is well again. It is a Pinescript limitation issue and happens when certain functions or variables don't get used at least once within the first 244 bars.
3B) Adjust your settings to hopefully find a divergence within the first 244 bars. If one is found then the problematic variables or functions should get used and the Pinescript 244 bar limitation should be temporarily resolved.
3C) Wait for X number of new bars to occur. If a divergence is eventually found within the first 244 bars that should solve the issue.
Tips:
1) If the amount that a setting changes value is undesirable for each time you click it then you can change that amount in the code. To do that, you'll need your own copy of my script. To make your own copy just click on "create a working copy" in the brown colored strip area above the code. Then within approximately the first 108 lines find the title of the setting you want to change. Then look to it's right to find the parameter called "step =". Change what the step equals to whatever you want. FYI, you can hover your mouse over the blue colored code and a popup will tell you what parameters(i.e. settings) that function(e.g. "input.int()") has available.
Wyszukaj w skryptach "THE SCRIPT"
Delta Volume Channels [LucF]█ OVERVIEW
This indicator displays on-chart visuals aimed at making the most of delta volume information. It can color bars and display two channels: one for delta volume, another calculated from the price levels of bars where delta volume divergences occur. Markers and alerts can also be configured using key conditions, and filtered in many different ways. The indicator caters to traders who prefer chart visuals over raw values. It will work on historical bars and in real time, using intrabar analysis to calculate delta volume in both conditions.
█ CONCEPTS
Delta Volume
The volume delta concept divides a bar's volume in "up" and "down" volumes. The delta is calculated by subtracting down volume from up volume. Many calculation techniques exist to isolate up and down volume within a bar. The simplest techniques use the polarity of interbar price changes to assign their volume to up or down slots, e.g., On Balance Volume or the Klinger Oscillator . Others such as Chaikin Money Flow use assumptions based on a bar's OHLC values. The most precise calculation method uses tick data and assigns the volume of each tick to the up or down slot depending on whether the transaction occurs at the bid or ask price. While this technique is ideal, it requires huge amounts of data on historical bars, which usually limits the historical depth of charts and the number of symbols for which tick data is available.
This indicator uses intrabar analysis to achieve a compromise between the simplest and most precise methods of calculating volume delta. In the context where historical tick data is not yet available on TradingView, intrabar analysis is the most precise technique to calculate volume delta on historical bars on our charts. TradingView's Volume Profile built-in indicators use it, as do the CVD - Cumulative Volume Delta Candles and CVD - Cumulative Volume Delta (Chart) indicators published from the TradingView account . My Volume Delta Columns Pro indicator also uses intrabar analysis. Other volume delta indicators such as my Realtime 5D Profile use realtime chart updates to achieve more precise volume delta calculations. Indicators of that type cannot be used on historical bars however; they only work in real time.
This is the logic I use to assign intrabar volume to up or down slots:
• If the intrabar's open and close values are different, their relative position is used.
• If the intrabar's open and close values are the same, the difference between the intrabar's close and the previous intrabar's close is used.
• As a last resort, when there is no movement during an intrabar and it closes at the same price as the previous intrabar, the last known polarity is used.
Once all intrabars making up a chart bar have been analyzed and the up or down property of each intrabar's volume determined, the up volumes are added and the down volumes subtracted. The resulting value is volume delta for that chart bar, which can be used as an estimate of the buying/selling pressure on an instrument.
Delta Volume Percent (DV%)
This value is the proportion that delta volume represents of the total intrabar volume in the chart bar. Note that on some symbols/timeframes, the total intrabar volume may differ from the chart's volume for a bar, but that will not affect our calculations since we use the total intrabar volume.
Delta Volume Channel
The DV channel is the space between two moving averages: the reference line and a DV%-weighted version of that reference. The reference line is a moving average of a type, source and length which you select. The DV%-weighted line uses the same settings, but it averages the DV%-weighted price source.
The weight applied to the source of the reference line is calculated from two values, which are multiplied: DV% and the relative size of the bar's volume in relation to previous bars. The effect of this is that DV% values on bars with higher total volume will carry greater weight than those with lesser volume.
The DV channel can be in one of four states, each having its corresponding color:
• Bull (teal): The DV%-weighted line is above the reference line.
• Strong bull (lime): The bull condition is fulfilled and the bar's close is above the reference line and both the reference and the DV%-weighted lines are rising.
• Bear (maroon): The DV%-weighted line is below the reference line.
• Strong bear (pink): The bear condition is fulfilled and the bar's close is below the reference line and both the reference and the DV%-weighted lines are falling.
Divergences
In the context of this indicator, a divergence is any bar where the slope of the reference line does not match that of the DV%-weighted line. No directional bias is assigned to divergences when they occur.
Divergence Channel
The divergence channel is the space between two levels (by default, the bar's low and high ) saved when divergences occur. When price has breached a channel and a new divergence occurs, a new channel is created. Until that new channel is breached, bars where additional divergences occur will expand the channel's levels if the bar's price points are outside the channel.
Prices breaches of the divergence channel will change its state. Divergence channels can be in one of five different states:
• Bull (teal): Price has breached the channel to the upside.
• Strong bull (lime): The bull condition is fulfilled and the DV channel is in the strong bull state.
• Bear (maroon): Price has breached the channel to the downside.
• Strong bear (pink): The bear condition is fulfilled and the DV channel is in the strong bear state.
• Neutral (gray): The channel has not been breached.
█ HOW TO USE THE INDICATOR
Load the indicator on an active chart (see here if you don't know how).
The default configuration displays:
• The DV channel, without the reference or DV%-weighted lines.
• The Divergence channel, without its level lines.
• Bar colors using the state of the DV channel.
The default settings use an Arnaud-Legoux moving average on the close and a length of 20 bars. The DV%-weighted version of it uses a combination of DV% and relative volume to calculate the ultimate weight applied to the reference. The DV%-weighted line is capped to 5 standard deviations of the reference. The lower timeframe used to access intrabars automatically adjusts to the chart's timeframe and achieves optimal balance between the number of intrabars inspected in each chart bar, and the number of chart bars covered by the script's calculations.
The Divergence channel's levels are determined using the high and low of the bars where divergences occur. Breaches of the channel require a bar's low to move above the top of the channel, and the bar's high to move below the channel's bottom.
No markers appear on the chart; if you want to create alerts from this script, you will need first to define the conditions that will trigger the markers, then create the alert, which will trigger on those same conditions.
To learn more about how to use this indicator, you must understand the concepts it uses and the information it displays, which requires reading this description. There are no videos to explain it.
█ FEATURES
The script's inputs are divided in four sections: "DV channel", "Divergence channel", "Other Visuals" and "Marker/Alert Conditions". The first setting is the selection method used to determine the intrabar precision, i.e., how many lower timeframe bars (intrabars) are examined in each chart bar. The more intrabars you analyze, the more precise the calculation of DV% results will be, but the less chart coverage can be covered by the script's calculations.
DV Channel
Here, you control the visibility and colors of the reference line, its weighted version, and the DV channel between them.
You also specify what type of moving average you want to use as a reference line, its source and length. This acts as the DV channel's baseline. The DV%-weighted line is also a moving average of the same type and length as the reference line, except that it will be calculated from the DV%-weighted source used in the reference line. By default, the DV%-weighted line is capped to five standard deviations of the reference line. You can change that value here. This section is also where you can disable the relative volume component of the weight.
Divergence Channel
This is where you control the appearance of the divergence channel and the key price values used in determining the channel's levels and breaching conditions. These choices have an impact on the behavior of the channel. More generous level prices like the default low and high selection will produce more conservative channels, as will the default choice for breach prices.
In this section, you can also enable a mode where an attempt is made to estimate the channel's bias before price breaches the channel. When it is enabled, successive increases/decreases of the channel's top and bottom levels are counted as new divergences occur. When one count is greater than the other, a bull/bear bias is inferred from it.
Other Visuals
You specify here:
• The method used to color chart bars, if you choose to do so.
• The display of a mark appearing above or below bars when a divergence occurs.
• If you want raw values to appear in tooltips when you hover above chart bars. The default setting does not display them, which makes the script faster.
• If you want to display an information box which by default appears in the lower left of the chart.
It shows which lower timeframe is used for intrabars, and the average number of intrabars per chart bar.
Marker/Alert Conditions
Here, you specify the conditions that will trigger up or down markers. The trigger conditions can include a combination of state transitions of the DV and the divergence channels. The triggering conditions can be filtered using a variety of conditions.
Configuring the marker conditions is necessary before creating an alert from this script, as the alert will use the marker conditions to trigger.
Markers only appear on bar closes, so they will not repaint. Keep in mind, when looking at markers on historical bars, that they are positioned on the bar when it closes — NOT when it opens.
Raw values
The raw values calculated by this script can be inspected using a tooltip and the Data Window. The tooltip is visible when you hover over the top of chart bars. It will display on the last 500 bars of the chart, and shows the values of DV, DV%, the combined weight, and the intermediary values used to calculate them.
█ INTERPRETATION
The aim of the DV channel is to provide a visual representation of the buying/selling pressure calculated using delta volume. The simplest characteristic of the channel is its bull/bear state. One can then distinguish between its bull and strong bull states, as transitions from strong bull to bull states will generally happen when buyers are losing steam. While one should not infer a reversal from such transitions, they can be a good place to tighten stops. Only time will tell if a reversal will occur. One or more divergences will often occur before reversals.
The nature of the divergence channel's design makes it particularly adept at identifying consolidation areas if its settings are kept on the conservative side. A gray divergence channel should usually be considered a no-trade zone. More adventurous traders can use the DV channel to orient their trade entries if they accept the risk of trading in a neutral divergence channel, which by definition will not have been breached by price.
If your charts are already busy with other stuff you want to hold on to, you could consider using only the chart bar coloring component of this indicator:
At its simplest, one way to use this indicator would be to look for overlaps of the strong bull/bear colors in both the DV channel and a divergence channel, as these identify points where price is breaching the divergence channel when buy/sell pressure is consistent with the direction of the breach. I have highlighted all those points in the chart below. Not all of them would have produced profitable trades, but nothing is perfect in the markets. Also, keep in mind that the circles identify the visual you would be looking for — not the trade's entry level.
█ LIMITATIONS
• The script will not work on symbols where no volume is available. An error will appear when that is the case.
• Because a maximum of 100K intrabars can be analyzed by a script, a compromise is necessary between the number of intrabars analyzed per chart bar
and chart coverage. The more intrabars you analyze per chart bar, the less coverage you will obtain.
The setting of the "Intrabar precision" field in the "DV channel" section of the script's inputs
is where you control how the lower timeframe is calculated from the chart's timeframe.
█ NOTES
Volume Quality
If you use volume, it's important to understand its nature and quality, as it varies with sectors and instruments. My Volume X-ray indicator is one way you can appraise the quality of an instrument's intraday volume.
For Pine Script™ Coders
• This script uses the new overload of the fill() function which now makes it possible to do vertical gradients in Pine. I use it for both channels displayed by this script.
• I use the new arguments for plot() 's `display` parameter to control where the script plots some of its values,
namely those I only want to appear in the script's status line and in the Data Window.
• I wrote my script using the revised recommendations in the Style Guide from the Pine v5 User Manual.
█ THANKS
To PineCoders . I have used their lower_tf library in this script, to manage the calculation of the LTF and intrabar stats, and their Time library to convert a timeframe in seconds to a printable form for its display in the Information box.
To TradingView's Pine Script™ team. Their innovations and improvements, big and small, constantly expand the boundaries of the language. What this script does would not have been possible just a few months back.
And finally, thanks to all the users of my scripts who take the time to comment on my publications and suggest improvements. I do not reply to all but I do read your comments and do my best to implement your suggestions with the limited time that I have.
Webhook Starter Kit [HullBuster]
Introduction
This is an open source strategy which provides a framework for webhook enabled projects. It is designed to work out-of-the-box on any instrument triggering on an intraday bar interval. This is a full featured script with an emphasis on actual trading at a brokerage through the TradingView alert mechanism and without requiring browser plugins.
The source code is written in a self documenting style with clearly defined sections. The sections “communicate” with each other through state variables making it easy for the strategy to evolve and improve. This is an excellent place for Pine Language beginners to start their strategy building journey. The script exhibits many Pine Language features which will certainly ad power to your script building abilities.
This script employs a basic trend follow strategy utilizing a forward pyramiding technique. Trend detection is implemented through the use of two higher time frame series. The market entry setup is a Simple Moving Average crossover. Positions exit by passing through conditional take profit logic. The script creates ten indicators including a Zscore oscillator to measure support and resistance levels. The indicator parameters are exposed through 47 strategy inputs segregated into seven sections. All of the inputs are equipped with detailed tool tips to help you get started.
To improve the transition from simulation to execution, strategy.entry and strategy.exit calls show enhanced message text with embedded keywords that are combined with the TradingView placeholders at alert time. Thereby, enabling a single JSON message to generate multiple execution events. This is genius stuff from the Pine Language development team. Really excellent work!
This document provides a sample alert message that can be applied to this script with relatively little modification. Without altering the code, the strategy inputs can alter the behavior to generate thousands of orders or simply a few dozen. It can be applied to crypto, stocks or forex instruments. A good way to look at this script is as a webhook lab that can aid in the development of your own endpoint processor, impress your co-workers and have hours of fun.
By no means is a webhook required or even necessary to benefit from this script. The setups, exits, trend detection, pyramids and DCA algorithms can be easily replaced with more sophisticated versions. The modular design of the script logic allows you to incrementally learn and advance this script into a functional trading system that you can be proud of.
Design
This is a trend following strategy that enters long above the trend line and short below. There are five trend lines that are visible by default but can be turned off in Section 7. Identified, in frequency order, as follows:
1. - EMA in the chart time frame. Intended to track price pressure. Configured in Section 3.
2. - ALMA in the higher time frame specified in Section 2 Signal Line Period.
3. - Linear Regression in the higher time frame specified in Section 2 Signal Line Period.
4. - Linear Regression in the higher time frame specified in Section 2 Signal Line Period.
5. - DEMA in the higher time frame specified in Section 2 Trend Line Period.
The Blue, Green and Orange lines are signal lines are on the same time frame. The time frame selected should be at least five times greater than the chart time frame. The Purple line represents the trend line for which prices above the line suggest a rising market and prices below a falling market. The time frame selected for the trend should be at least five times greater than the signal lines.
Three oscillators are created as follows:
1. Stochastic - In the chart time frame. Used to enter forward pyramids.
2. Stochastic - In the Trend period. Used to detect exit conditions.
3. Zscore - In the Signal period. Used to detect exit conditions.
The Stochastics are configured identically other than the time frame. The period is set in Section 2.
Two Simple Moving Averages provide the trade entry conditions in the form of a crossover. Crossing up is a long entry and down is a short. This is in fact the same setup you get when you select a basic strategy from the Pine editor. The crossovers are configured in Section 3. You can see where the crosses are occurring by enabling Show Entry Regions in Section 7.
The script has the capacity for pyramids and DCA. Forward pyramids are enabled by setting the Pyramid properties tab with a non zero value. In this case add on trades will enter the market on dips above the position open price. This process will continue until the trade exits. Downward pyramids are available in Crypto and Range mode only. In this case add on trades are placed below the entry price in the drawdown space until the stop is hit. To enable downward pyramids set the Pyramid Minimum Span In Section 1 to a non zero value.
This implementation of Dollar Cost Averaging (DCA) triggers off consecutive losses. Each loss in a run increments a sequence number. The position size is increased as a multiple of this sequence. When the position eventually closes at a profit the sequence is reset. DCA is enabled by setting the Maximum DCA Increments In Section 1 to a non zero value.
It should be noted that the pyramid and DCA features are implemented using a rudimentary design and as such do not perform with the precision of my invite only scripts. They are intended as a feature to stress test your webhook endpoint. As is, you will need to buttress the logic for it to be part of an automated trading system. It is for this reason that I did not apply a Martingale algorithm to this pyramid implementation. But, hey, it’s an open source script so there is plenty of room for learning and your own experimentation.
How does it work
The overall behavior of the script is governed by the Trading Mode selection in Section 1. It is the very first input so you should think about what behavior you intend for this strategy at the onset of the configuration. As previously discussed, this script is designed to be a trend follower. The trend being defined as where the purple line is predominately heading. In BiDir mode, SMA crossovers above the purple line will open long positions and crosses below the line will open short. If pyramiding is enabled add on trades will accumulate on dips above the entry price. The value applied to the Minimum Profit input in Section 1 establishes the threshold for a profitable exit. This is not a hard number exit. The conditional exit logic must be satisfied in order to permit the trade to close. This is where the effort put into the indicator calibration is realized. There are four ways the trade can exit at a profit:
1. Natural exit. When the blue line crosses the green line the trade will close. For a long position the blue line must cross under the green line (downward). For a short the blue must cross over the green (upward).
2. Alma / Linear Regression event. The distance the blue line is from the green and the relative speed the cross is experiencing determines this event. The activation thresholds are set in Section 6 and relies on the period and length set in Section 2. A long position will exit on an upward thrust which exceeds the activation threshold. A short will exit on a downward thrust.
3. Exponential event. The distance the yellow line is from the blue and the relative speed the cross is experiencing determines this event. The activation thresholds are set in Section 3 and relies on the period and length set in the same section.
4. Stochastic event. The purple line stochastic is used to measure overbought and over sold levels with regard to position exits. Signal line positions combined with a reading over 80 signals a long profit exit. Similarly, readings below 20 signal a short profit exit.
Another, optional, way to exit a position is by Bale Out. You can enable this feature in Section 1. This is a handy way to reduce the risk when carrying a large pyramid stack. Instead of waiting for the entire position to recover we exit early (bale out) as soon as the profit value has doubled.
There are lots of ways to implement a bale out but the method I used here provides a succinct example. Feel free to improve on it if you like. To see where the Bale Outs occur, enable Show Bale Outs in Section 7. Red labels are rendered below each exit point on the chart.
There are seven selectable Trading Modes available from the drop down in Section 1:
1. Long - Uses the strategy.risk.allow_entry_in to execute long only trades. You will still see shorts on the chart.
2. Short - Uses the strategy.risk.allow_entry_in to execute short only trades. You will still see long trades on the chart.
3. BiDir - This mode is for margin trading with a stop. If a long position was initiated above the trend line and the price has now fallen below the trend, the position will be reversed after the stop is hit. Forward pyramiding is available in this mode if you set the Pyramiding value in the Properties tab. DCA can also be activated.
4. Flip Flop - This is a bidirectional trading mode that automatically reverses on a trend line crossover. This is distinctively different from BiDir since you will get a reversal even without a stop which is advantageous in non-margin trading.
5. Crypto - This mode is for crypto trading where you are buying the coins outright. In this case you likely want to accumulate coins on a crash. Especially, when all the news outlets are talking about the end of Bitcoin and you see nice deep valleys on the chart. Certainly, under these conditions, the market will be well below the purple line. No margin so you can’t go short. Downward pyramids are enabled for Crypto mode when two conditions are met. First the Pyramiding value in the Properties tab must be non zero. Second the Pyramid Minimum Span in Section 1 must be non zero.
6. Range - This is a counter trend trading mode. Longs are entered below the purple trend line and shorts above. Useful when you want to test your webhook in a market where the trend line is bisecting the signal line series. Remember that this strategy is a trend follower. It’s going to get chopped out in a range bound market. By turning on the Range mode you will at least see profitable trades while stuck in the range. However, when the market eventually picks a direction, this mode will sustain losses. This range trading mode is a rudimentary implementation that will need a lot of improvement if you want to create a reliable switch hitter (trend/range combo).
7. No Trade. Useful when setting up the trend lines and the entry and exit is not important.
Once in the trade, long or short, the script tests the exit condition on every bar. If not a profitable exit then it checks if a pyramid is required. As mentioned earlier, the entry setups are quite primitive. Although they can easily be replaced by more sophisticated algorithms, what I really wanted to show is the diminished role of the position entry in the overall life of the trade. Professional traders spend much more time on the management of the trade beyond the market entry. While your trade entry is important, you can get in almost anywhere and still land a profitable exit.
If DCA is enabled, the size of the position will increase in response to consecutive losses. The number of times the position can increase is limited by the number set in Maximum DCA Increments of Section 1. Once the position breaks the losing streak the trade size will return the default quantity set in the Properties tab. It should be noted that the Initial Capital amount set in the Properties tab does not affect the simulation in the same way as a real account. In reality, running out of money will certainly halt trading. In fact, your account would be frozen long before the last penny was committed to a trade. On the other hand, TradingView will keep running the simulation until the current bar even if your funds have been technically depleted.
Entry and exit use the strategy.entry and strategy.exit calls respectfully. The alert_message parameter has special keywords that the endpoint expects to properly calculate position size and message sequence. The alert message will embed these keywords in the JSON object through the {{strategy.order.alert_message}} placeholder. You should use whatever keywords are expected from the endpoint you intend to webhook in to.
Webhook Integration
The TradingView alerts dialog provides a way to connect your script to an external system which could actually execute your trade. This is a fantastic feature that enables you to separate the data feed and technical analysis from the execution and reporting systems. Using this feature it is possible to create a fully automated trading system entirely on the cloud. Of course, there is some work to get it all going in a reliable fashion. Being a strategy type script place holders such as {{strategy.position_size}} can be embedded in the alert message text. There are more than 10 variables which can write internal script values into the message for delivery to the specified endpoint.
Entry and exit use the strategy.entry and strategy.exit calls respectfully. The alert_message parameter has special keywords that my endpoint expects to properly calculate position size and message sequence. The alert message will embed these keywords in the JSON object through the {{strategy.order.alert_message}} placeholder. You should use whatever keywords are expected from the endpoint you intend to webhook in to.
Here is an excerpt of the fields I use in my webhook signal:
"broker_id": "kraken",
"account_id": "XXX XXXX XXXX XXXX",
"symbol_id": "XMRUSD",
"action": "{{strategy.order.action}}",
"strategy": "{{strategy.order.id}}",
"lots": "{{strategy.order.contracts}}",
"price": "{{strategy.order.price}}",
"comment": "{{strategy.order.alert_message}}",
"timestamp": "{{time}}"
Though TradingView does a great job in dispatching your alert this feature does come with a few idiosyncrasies. Namely, a single transaction call in your script may cause multiple transmissions to the endpoint. If you are using placeholders each message describes part of the transaction sequence. A good example is closing a pyramid stack. Although the script makes a single strategy.close() call, the endpoint actually receives a close message for each pyramid trade. The broker, on the other hand, only requires a single close. The incongruity of this situation is exacerbated by the possibility of messages being received out of sequence. Depending on the type of order designated in the message, a close or a reversal. This could have a disastrous effect on your live account. This broker simulator has no idea what is actually going on at your real account. Its just doing the job of running the simulation and sending out the computed results. If your TradingView simulation falls out of alignment with the actual trading account lots of really bad things could happen. Like your script thinks your are currently long but the account is actually short. Reversals from this point forward will always be wrong with no one the wiser. Human intervention will be required to restore congruence. But how does anyone find out this is occurring? In closed systems engineering this is known as entropy. In practice your webhook logic should be robust enough to detect these conditions. Be generous with the placeholder usage and give the webhook code plenty of information to compare states. Both issuer and receiver. Don’t blindly commit incoming signals without verifying system integrity.
Setup
The following steps provide a very brief set of instructions that will get you started on your first configuration. After you’ve gone through the process a couple of times, you won’t need these anymore. It’s really a simple script after all. I have several example configurations that I used to create the performance charts shown. I can share them with you if you like. Of course, if you’ve modified the code then these steps are probably obsolete.
There are 47 inputs divided into seven sections. For the most part, the configuration process is designed to flow from top to bottom. Handy, tool tips are available on every field to help get you through the initial setup.
Step 1. Input the Base Currency and Order Size in the Properties tab. Set the Pyramiding value to zero.
Step 2. Select the Trading Mode you intend to test with from the drop down in Section 1. I usually select No Trade until I’ve setup all of the trend lines, profit and stop levels.
Step 3. Put in your Minimum Profit and Stop Loss in the first section. This is in pips or currency basis points (chart right side scale). Remember that the profit is taken as a conditional exit not a fixed limit. The actual profit taken will almost always be greater than the amount specified. The stop loss, on the other hand, is indeed a hard number which is executed by the TradingView broker simulator when the threshold is breached.
Step 4. Apply the appropriate value to the Tick Scalar field in Section 1. This value is used to remove the pipette from the price. You can enable the Summary Report in Section 7 to see the TradingView minimum tick size of the current chart.
Step 5. Apply the appropriate Price Normalizer value in Section 1. This value is used to normalize the instrument price for differential calculations. Basically, we want to increase the magnitude to significant digits to make the numbers more meaningful in comparisons. Though I have used many normalization techniques, I have always found this method to provide a simple and lightweight solution for less demanding applications. Most of the time the default value will be sufficient. The Tick Scalar and Price Normalizer value work together within a single calculation so changing either will affect all delta result values.
Step 6. Turn on the trend line plots in Section 7. Then configure Section 2. Try to get the plots to show you what’s really happening not what you want to happen. The most important is the purple trend line. Select an interval and length that seem to identify where prices tend to go during non-consolidation periods. Remember that a natural exit is when the blue crosses the green line.
Step 7. Enable Show Event Regions in Section 7. Then adjust Section 6. Blue background fills are spikes and red fills are plunging prices. These measurements should be hard to come by so you should see relatively few fills on the chart if you’ve set this up as intended. Section 6 includes the Zscore oscillator the state of which combines with the signal lines to detect statistically significant price movement. The Zscore is a zero based calculation with positive and negative magnitude readings. You want to input a reasonably large number slightly below the maximum amplitude seen on the chart. Both rise and fall inputs are entered as a positive real number. You can easily use my code to create a separate indicator if you want to see it in action. The default value is sufficient for most configurations.
Step 8. Turn off Show Event Regions and enable Show Entry Regions in Section 7. Then adjust Section 3. This section contains two parts. The entry setup crossovers and EMA events. Adjust the crossovers first. That is the Fast Cross Length and Slow Cross Length. The frequency of your trades will be shown as blue and red fills. There should be a lot. Then turn off Show Event Regions and enable Display EMA Peaks. Adjust all the fields that have the word EMA. This is actually the yellow line on the chart. The blue and red fills should show much less than the crossovers but more than event fills shown in Step 7.
Step 9. Change the Trading Mode to BiDir if you selected No Trades previously. Look on the chart and see where the trades are occurring. Make adjustments to the Minimum Profit and Stop Offset in Section 1 if necessary. Wider profits and stops reduce the trade frequency.
Step 10. Go to Section 4 and 5 and make fine tuning adjustments to the long and short side.
Example Settings
To reproduce the performance shown on the chart please use the following configuration: (Bitcoin on the Kraken exchange)
1. Select XBTUSD Kraken as the chart symbol.
2. On the properties tab set the Order Size to: 0.01 Bitcoin
3. On the properties tab set the Pyramiding to: 12
4. In Section 1: Select “Crypto” for the Trading Model
5. In Section 1: Input 2000 for the Minimum Profit
6. In Section 1: Input 0 for the Stop Offset (No Stop)
7. In Section 1: Input 10 for the Tick Scalar
8. In Section 1: Input 1000 for the Price Normalizer
9. In Section 1: Input 2000 for the Pyramid Minimum Span
10. In Section 1: Check mark the Position Bale Out
11. In Section 2: Input 60 for the Signal Line Period
12. In Section 2: Input 1440 for the Trend Line Period
13. In Section 2: Input 5 for the Fast Alma Length
14. In Section 2: Input 22 for the Fast LinReg Length
15. In Section 2: Input 100 for the Slow LinReg Length
16. In Section 2: Input 90 for the Trend Line Length
17. In Section 2: Input 14 Stochastic Length
18. In Section 3: Input 9 Fast Cross Length
19. In Section 3: Input 24 Slow Cross Length
20. In Section 3: Input 8 Fast EMA Length
21. In Section 3: Input 10 Fast EMA Rise NetChg
22. In Section 3: Input 1 Fast EMA Rise ROC
23. In Section 3: Input 10 Fast EMA Fall NetChg
24. In Section 3: Input 1 Fast EMA Fall ROC
25. In Section 4: Check mark the Long Natural Exit
26. In Section 4: Check mark the Long Signal Exit
27. In Section 4: Check mark the Long Price Event Exit
28. In Section 4: Check mark the Long Stochastic Exit
29. In Section 5: Check mark the Short Natural Exit
30. In Section 5: Check mark the Short Signal Exit
31. In Section 5: Check mark the Short Price Event Exit
32. In Section 5: Check mark the Short Stochastic Exit
33. In Section 6: Input 120 Rise Event NetChg
34. In Section 6: Input 1 Rise Event ROC
35. In Section 6: Input 5 Min Above Zero ZScore
36. In Section 6: Input 120 Fall Event NetChg
37. In Section 6: Input 1 Fall Event ROC
38. In Section 6: Input 5 Min Below Zero ZScore
In this configuration we are trading in long only mode and have enabled downward pyramiding. The purple trend line is based on the day (1440) period. The length is set at 90 days so it’s going to take a while for the trend line to alter course should this symbol decide to node dive for a prolonged amount of time. Your trades will still go long under those circumstances. Since downward accumulation is enabled, your position size will grow on the way down.
The performance example is Bitcoin so we assume the trader is buying coins outright. That being the case we don’t need a stop since we will never receive a margin call. New buy signals will be generated when the price exceeds the magnitude and speed defined by the Event Net Change and Rate of Change.
Feel free to PM me with any questions related to this script. Thank you and happy trading!
CFTC RULE 4.41
These results are based on simulated or hypothetical performance results that have certain inherent limitations. Unlike the results shown in an actual performance record, these results do not represent actual trading. Also, because these trades have not actually been executed, these results may have under-or over-compensated for the impact, if any, of certain market factors, such as lack of liquidity. Simulated or hypothetical trading programs in general are also subject to the fact that they are designed with the benefit of hindsight. No representation is being made that any account will or is likely to achieve profits or losses similar to these being shown.
Relative Volume at Time█ OVERVIEW
This indicator calculates relative volume, which is the ratio of present volume over an average of past volume.
It offers two calculation modes, both using a time reference as an anchor.
█ CONCEPTS
Calculation modes
The simplest way to calculate relative volume is by using the ratio of a bar's volume over a simple moving average of the last n volume values.
This indicator uses one of two, more subtle ways to calculate both values of the relative volume ratio: current volume:past volume .
The two calculations modes are:
1 — Cumulate from Beginning of TF to Current Bar where:
current volume = the cumulative volume since the beginning of the timeframe unit, and
past volume = the mean of volume during that same relative period of time in the past n timeframe units.
2 — Point-to-Point Bars at Same Offset from Beginning of TF where:
current volume = the volume on a single chart bar, and
past volume = the mean of volume values from that same relative bar in time from the past n timeframe units.
Timeframe units
Timeframe units can be defined in three different ways:
1 — Using Auto-steps, where the timeframe unit automatically adjusts to the timeframe used on the chart:
— A 1 min timeframe unit will be used on 1sec charts,
— 1H will be used for charts at 1min and less,
— 1D will be used for other intraday chart timeframes,
— 1W will be used for 1D charts,
— 1M will be used for charts at less than 1M,
— 1Y will be used for charts at greater or equal than 1M.
2 — As a fixed timeframe that you define.
3 — By time of day (for intraday chart timeframes only), which you also define. If you use non-intraday chart timeframes in this mode, the indicator will switch to Auto-steps.
Relative Relativity
A relative volume value of 1.0 indicates that current volume is equal to the mean of past volume , but how can we determine what constitutes a high relative volume value?
The traditional way is to settle for an arbitrary threshold, with 2.0 often used to indicate that relative volume is worthy of attention.
We wanted to provide traders with a contextual method of calculating threshold values, so in addition to the conventional fixed threshold value,
this indicator includes two methods of calculating a threshold channel on past relative volume values:
1 — Using the standard deviation of relative volume over a fixed lookback.
2 — Using the highs/lows of relative volume over a variable lookback.
Channels calculated on relative volume provide meta-relativity, if you will, as they are relative values of relative volume.
█ FEATURES
Controls in the "Display" section of inputs determine what is visible in the indicator's pane. The next "Settings" section is where you configure the parameters used in the calculations. The "Column Coloring Conditions" section controls the color of the columns, which you will see in three of the five display modes available. Whether columns are plotted or not, the coloring conditions also determine when markers appear, if you have chosen to show the markers in the "Display" section. The presence of markers is what triggers the alerts configured on this indicator. Finally, the "Colors" section of inputs allows you to control the color of the indicator's visual components.
Display
Five display modes are available:
• Current Volume Columns : shows columns of current volume , with past volume displayed as an outlined column.
• Relative Volume Columns : shows relative volume as a column.
• Relative Volume Columns With Average : shows relative volume as a column, with the average of relative volume.
• Directional Relative Volume Average : shows a line calculated using the average of +/- values of relative volume.
The positive value of relative volume is used on up bars; its negative value on down bars.
• Relative Volume Average : shows the average of relative volume.
A Hull moving average is used to calculate the average used in the three last display modes.
You can also control the display of:
• The value or relative volume, when in the first three display modes. Only the last 500 values will be shown.
• Timeframe transitions, shown in the background.
• A reminder of the active timeframe unit, which appears to the right of the indicator's last bar.
• The threshold used, which can be a fixed value or a channel, as determined in the next "Settings" section of inputs.
• Up/Down markers, which appear on transitions of the color of the volume columns (determined by coloring conditions), which in turn control when alerts are triggered.
• Conditions of high volatility.
Settings
Use this section of inputs to change:
• Calculation mode : this is where you select one of this indicator's two calculation modes for current volume and past volume , as explained in the "Concepts" section.
• Past Volume Lookback in TF units : the quantity of timeframe units used in the calculation of past volume .
• Define Timeframes Units Using : the mode used to determine what one timeframe unit is. Note that when using a fixed timeframe, it must be higher than the chart's timeframe.
Also, note that time of day timeframe units only work on intraday chart timeframes.
• Threshold Mode : Five different modes can be selected:
— Fixed Value : You can define the value using the "Fixed Threshold" field below. The default value is 2.0.
— Standard Deviation Channel From Fixed Lookback : This is a channel calculated using the simple moving average of relative volume
(so not the Hull moving average used elsewhere in the indicator), plus/minus the standard deviation multiplied by a user-defined factor.
The lookback used is the value of the "Channel Lookback" field. Its default is 100.
— High/Low Channel From Beginning of TF : in this mode, the High/Low values reset at the beginning of each timeframe unit.
— High/Low Channel From Beginning of Past Volume Lookback : in this mode, the High/Low values start from the farthest point back where we are calculating past volume ,
which is determined by the combination of timeframe units and the "Past Volume Lookback in TF units" value.
— High/Low Channel From Fixed Lookback : In this mode the lookback is fixed. You can define the value using the "Channel Lookback" field. The default value is 100.
• Period of RelVol Moving Average : the period of the Hull moving average used in the "Directional Relative Volume Average" and the "Relative Volume Average".
• High Volatility is defined using fast and slow ATR periods, so this represents the volatility of price.
Volatility is considered to be high when the fast ATR value is greater than its slow value. Volatility can be used as a filter in the column coloring conditions.
Column Coloring Conditions
• Eight different conditions can be turned on or off to determine the color of the volume columns. All "ON" conditions must be met to determine a high/low state of relative volume,
or, in the case of directional relative volume, a bull/bear state.
• A volatility state can also be used to filter the conditions.
• When the coloring conditions and the filter do not allow for a high/low state to be determined, the neutral color is used.
• Transitions of the color of the volume columns determined by coloring conditions are used to plot the up/down markers, which in turn control when alerts are triggered.
Colors
• You can define your own colors for all of the oscillator's plots.
• The default colors will perform well on light or dark chart backgrounds.
Alerts
• An alert can be defined for the script. The alert will trigger whenever an up/down marker appears in the indicator's display.
The particular combination of coloring conditions and the display settings for up/down markers when you create the alert will determine which conditions trigger the alert.
After alerts are created, subsequent changes to the conditions controlling the display of markers will not affect existing alerts.
• By configuring the script's inputs in different ways before you create your alerts, you can create multiple, functionally distinct alerts from this script.
When creating multiple alerts, it is useful to include in the alert's message a reminder of the particular conditions you used for each alert.
• As is usually the case, alerts triggering "Once Per Bar Close" will prevent repainting.
Error messages
Error messages will appear at the end of the chart upon the following conditions:
• When the combination of the timeframe units used and the "Past Volume Lookback in TF units" value create a lookback that is greater than 5000 bars.
The lookback will then be recalculated to a value such that a runtime error does not occur.
• If the chart's timeframe is higher than the timeframe units. This error cannot occur when using Auto-steps to calculate timeframe units.
• If relative volume cannot be calculated, for example, when no volume data is available for the chart's symbol.
• When the threshold of relative volume is configured to be visible but the indicator's scale does not allow it to be visible (in "Current Volume Columns" display mode).
█ NOTES
For traders
The chart shown here uses the following display modes: "Current Volume Columns", "Relative Volume Columns With Average", "Directional Relative Volume Average" and "Relative Volume Average". The last one also shows the threshold channel in standard deviation mode, and the TF Unit reminder to the right, in red.
Volume, like price, is a value with a market-dependent scale. The only valid reference for volume being its past values, any improvement in the way past volume is calculated thus represents a potential opportunity to traders. Relative volume calculated as it is here can help traders extract useful information from markets in many circumstances, markets with cyclical volume such as Forex being one, obvious case. The relative nature of the values calculated by this indicator also make it a natural fit for cross-market and cross-sector analysis, or to identify behavioral changes in the different futures contracts of the same market. Relative volume can also be put to more exotic uses, such as in evaluating changes in the popularity of exchanges.
Relative volume alone has no directional bias. While higher relative volume values always indicate higher trading activity, that activity does not necessarily translate into significant price movement. In a tightly fought battle between buyers and sellers, you could theoretically have very large volume for many bars, with no change whatsoever in bid/ask prices. This of course, is unlikely to happen in reality, and so traders are justified in considering high relative volume values as indicating periods where more attention is required, because imbalances in the strength of buying/selling power during high-volume trading periods can amplify price variations, providing traders with the generally useful gift of volatility.
Be sure to give the "Directional Relative Volume Average" a try. Contrary to the always-positive ratio widely used in this indicator, the "Directional Relative Volume Average" produces a value able to determine a bullish/bearish bias for relative volume.
Note that realtime bars must be complete for the relative volume value to be confirmed. Values calculated on historical or elapsed realtime bars will not recalculate unless historical volume data changes.
Finally, as with all indicators using volume information, keep in mind that some exchanges/brokers supply different feeds for intraday and daily data, and the volume data on both feeds can sometimes vary quite a bit.
For coders
Our script was written using the PineCoders Coding Conventions for Pine .
The description was formatted using the techniques explained in the How We Write and Format Script Descriptions PineCoders publication.
Bits and pieces of code were lifted from the MTF Selection Framework and the MTF Oscillator Framework , also by PineCoders.
█ THANKS
Thanks to dgtrd for suggesting to add the channel using standard deviation.
Thanks to adolgov for helpful suggestions on calculations and visuals.
Look first. Then leap.
Weekly/Daily/Hourly/Minutes Colored Background IntervalsThis is my "Weekly/Daily/Hourly/Minutes Colored Background Intervals" assistant. I wouldn't describe it as an indicator, it just exhibits coloration of referenced periods of time with bgcolor() in Pine. With the arrival of 2021, I pondered the necessity of needing a visualization pre-2021 to visually recognize periodicity of market movements by the week, day, hour, or an adjustable period of minutes. While this script is simply generic, I hope you may find useful in your endeavors as a member on TradingView.
Explaining the script's usage, the "Minutes" input can be adjusted from anywhere between 5-55 minutes for only intraday. This can be modified to accommodate 90 minutes (1.5hrs) or any other minutes period desirable by tweaking certain numbers up to 1440. Minutes and Hourly backgrounds are disabled by default for most daily traders. Changing the input() code to `true` will provide them on by default when the script loads, if you choose that route. Each time periods background color is enable/disable capable. All of the colors are easily adjustable to any combination you can ponder for your visual acuity with the color swatch provided by input(type=input.color). The coloring can be "swapped" by input() depending on how you wish to start and end the day visually. I thought this would come in handy. The weekly background can have different starting points, whether it be Sunday, Monday, or any other day such as Friday for example.
The entire script's contents isn't intended for complete re-use as is for publicly published scripts. It's more along the lines of code that could be used to personally modify indicators you have, depending on the time frames you may actually be trading on. The code is basically modular, so you can use bits and pieces of it in your personally modified Pine Editor scripts that you wish to customize for yourself. I will say that the isXxx() functions are completely reusable in any script without any need for author permission inquiries from me, as easy as copy and paste. Those may come in handy for many folks. If you find them useful in certain circumstances, use isXxx() functions as you please. Day of the week detection by functions will have applications beyond my current intended use for them.
Of notable mention, this is a miniature lesson by example of how the new input(type=input.color) may be used. I'm also using `var` inside functions to aid in computational efficiency of the script runtime. The colors are permanently stored at the very beginning of the scripts operation inside the function and just reused from that point onward. Its a rare use case, but well suited for this scripts intention. Once again I have demonstrated the "Power of Pine" for developers of any experience level to learn from via code elegance.
When available time provides itself, I will consider your inquiries, thoughts, and concepts presented below in the comments section, should you have any questions or comments regarding this indicator. When my indicators achieve more prevalent use by TV members , I may implement more ideas when they present themselves as worthy additions. Have a profitable future everyone!
Bogdan Ciocoiu - Sniper EntryWhat is Sniper Entry
Sniper Entry is a set indicator that encapsulates a collection of pre-configured scripts using specific variables that enable users to extract signals by interpreting market behaviour quickly, suitable for 1-3min scalping. This instrument is a tool that acts as a confluence for traders to make decisions concerning current market conditions. This indicator does not apply solely to an asset.
What Sniper Entry is not
Sniper Entry is not interpreting fundamental analysis and will also not be providing out of box market signals. Instead, it will provide a collection of integrated and significantly improved open-source subscripts designed to help traders speculate on market trends. Traders must apply their strategies and configure Sniper Entry accordingly to maximise the script's output.
Originality and usefulness
The collection of subscripts encapsulated in this tool makes it unique in the Trading View ecosystem. This indicator enables traders to consider entry positions or exit positions by comparing similar algorithms at once.
Its usefulness also emerges from the unique configurations embedded in the indicator's settings, which are different from those of the original scripts.
This indicator's originality is also reflected in how its modules are integrated, including the integration of the settings.
Open-source reuse
I used the following open-source resources, which I simplified significantly and pre-configured for short term scalping. The source codes for the below are already in the public domain, including the following links listed below.
www.tradingview.com (open source)
(open source and generic algorithm)
www.tradingview.com (open source)
(open source)
(open source)
www.tradingview.com (generic MA algorithm and open source)
(generic VWAP algorithm and open source)
Scanner/Screener of Over 40 Coins Per Script I am very scatter-brained by nature and sporadic in my thought processes but if these benefit the community and ya'll ask for more perhaps I will get better and even out a tad....probably not....but you never know. Firstly, allow me to apologize to all the vet/more sophisticated coders out there whose eyes and brains might just be overly taxed due to my poor coding structure. Im just getting started for the first time in ANY sort of coding...so cut me a little slack. Also, if anyone sees any mistakes or the functionality is not as I proclaimed, PLEASE do let me know. In these past 12mo of me learning my 1st coding language (Pinescript) I would say that I have been intently focused on creating all types/sorts of scanners/screeners. Ive always hoped to be a benefit to the community as I was always SO grateful to those who have come before me that have led me to the little bit of progress I have made with Pinescript. This script is not necessarily something that should be traded with as it is just a thrown together example showing a scanner/screener whose results produce plot outputs (ie, Rate of Change / oscillators as well / etc) and how they can be used in the alert system so that only 1 alert has to be set per iteration of the script but more importantly how to use/scan/screen with over 40 coins per script. My intent is not to trick anyone here. So to be PERFECTLY CLEAR, more than 40 coins CAN in fact be screened/scanned from one script (here I am doing all of KUCOIN's Margin Coins...72 total I look at)...BUT...(heres the catch) it must be added to the chart however many times EQUAL to the amount of "sets" you have in your script. (Heres the limitation by TV) There cannot be more than 40 coins in each "set". The less coins you have per set, the quicker the script will startup and run, thus, the quicker alerts will be received if automating the process. Though, if you only have the free plan and can only have MAX 3 indicators per chart then the MAX you can screen at a time is 120 coins if you use 40 coins per set. So, this is the first one I would like to introduce. For this one your screener/scanner must be using some sort of plots as output that is being screened for. (original inspiration of ALL my variations mainly come from @QuantNomad, @daveatt, and @LonesomeTheBlue (and a few others I may be forgetting at the moment). Thanks for the inspiration through countless publications that ya'll have created for us in the community.
Some of my variations are more complex/elegant than others but there are MANY very different ones that I would like to share with the community. If you leave a comment and wonder why I have not responded but did so to every comment around yours...see if you are one of the individuals in this next few sentences...and if you are then perhaps someone else would like to waste their time responding to your comment...but basically, if you don't want to spend the time helping yourself by reading the title, description section, AND the comments section (at least scanning them) then I am MOST DEFINITELY not going to help you down your path of destruction that is most likely soon to be your blown-up trading account. I was called a "masochist" after asking for guidance on if its worth the headache to publish anything on TV bc there will NO DOUBT be comments that'll make me wish I didn't (ie. someone CLEARLY not reading the description (or seemingly even the title sometimes) bc they make a comment that has been explicitly addressed, or someone asking to rebuild the code compatible for another charting software or whatnot, or how about those asking if it repaints (this one is almost always addressed in the comments section but I can understand this question more than others as Im only 1 yr into learning any sort of coding for the first time in the beginning I saw people ask on EVERY script about if it repainted and it was worrisome at the lest (esp bc I didn't even understand what it was not so long ago, or my favorite...what TF it works best on...these people CLEARLY need not be trading yet if your still asking questions as such...Ill end it there). Point being, Ive got some truly VERY useful scripts that I want to share and as long as these people don't make me regret doing so in the beginning, then whats mine...will soon be yours. Though, I will take a little time between the releases.
YOU GUYS (TV and its community) ARE AWESOME (most of you anyways ;)
MUCH LOVE,
ChasinAlts
(1) INPUTS
Here is where the "sets" come in. I am looking at all of KUCOIN's Margin Coins (72 of them at least) so am splitting them up into 3 sets/iterations and a copy of the script must be added equal to amount of "sets" you have here. This is the ONLY workaround I have found to be able to scan/screen with more than 40 coins per script (due to TV's limitation of 40 Security Calls per script) ***So for everyone saying it's impossible scan more than 40 Coins per scipt...it' MOST DEFINITELY possible....BUT ONLY by adding this script multiple times on the chart and selecting 1 of each of the "sets" in the script settings via the chart window. To save the much needed room you must push each iteration of the script into 1 window and merging the scales of each into 1 scale(ie. "Scale A") within the settings of the script name on the chart(3 horizontal dots)
(2) FUNCTION
(2.1) COLORIDs
This is just to set up all my Colors of plots which are being matched with their respective labels. I have a diff color for each of the 72 coins Im plotting so Im telling the function, "depending on which set of coins I select...give me this color out of the colors I input later into the function"
(2.2) TICKERID CONSTRUCTION
I construct the tickerID this way so that the labels on my plots have only the Coin's name vs the label having the (Exchange Name):(Coin Name)(Base Pair Name). If you are using more than 1 Base pair (ie. XRP/BTC and XRP/USDT and XRP/ETH) OR more than 1 Exchange OR want your plots to show MORE THAN just the Trading Coin's name, then the tickerID MUST BE constructed differently
(2.3) SECURITY CALL & PLOT OUTPUT VARIABLES
If using a Higher Time Frame in Security Call then it MUST BE adjusted to permit or dissallow repainting if you so wish (BEYOND THE SCOPE OF THIS PUBLICATION so Do Your Own Researh). If your MAIN LOGIC is more complex than simply using a TV built-in function), THEN it MUST BE built into its own function outside of this function and called on within the "expression" slot of this Security Call OR can also be built into this function and called on in the "expression" slot of this Security call (BEYOND THE SCOPE OF THIS PUB SO DYOR). FURTHERMORE...when you are using a series(ie high/low/close/open/hl2/etc) / bar_index / time / etc that will be specific to the Coin/tickerID, then they MUST BE explicitly used within the "expression" slot of the Security Function when calling on your Main Logic or else it will pull the series/time/bar_index/etc from the Coin that the Chart is presently on (BEYOND THE SCOPE OF THIS PUB SO DYOR)
(2.4) PLOT LABEL
This is the Plot's Label that will be next to the end of the plot on the LAST bar_index. ***Notice in the "text" slot of the label I have "_coin" (without the quotes obviously)...this is where have JUST the Coin's name comes into effect on the label vs the (Exchange Name):(Coin Name)(Base Pair Name) which looks MUCH cleaner
(2.5) ALERT LOGIC / ALERT LABEL
Your alert logic need not be as complex as this... I just wanted to create a decent enough timing for this system and wanted to simply print the labels displaying which coin produced the alert at the same time the alerts would go off. Alert is set up to Trigger Bullish when the ROC is below the Threshold and _chg > _chg X=length of bars inputted in "Rising/Falling Length" setting and vise versa for Bearish Alerts. If _chg plot only goes past threshold for a VERY few amount of bars NOT providing enough time for initial Alert to trigger, then alert/label triggers on crossing of threshold back towards 0(zero). ONLY 1 alert needs to be set per script to be able to scan ALL 72 of the coins as I have them in this script. Timing of Alert is inline with the name label printed past the thresholds.
(3) VARIABLES FROM MAIN FUNCTION
This is the tuple of the Main Function that outputs the variables from 3 lines up to be able to plot the lines and color them according to the colors on the labels. *** As of now, we CANNOT plot from within the function so MUST BE done this way to produce the variables and colors needed. The plots are the ONLY thing in this script that cannot be executed from within the function
(4) LINE PLOTS
ALL output variables from our Main Function are used here for the line plots
Monte Carlo Range Forecast [DW]This is an experimental study designed to forecast the range of price movement from a specified starting point using a Monte Carlo simulation.
Monte Carlo experiments are a broad class of computational algorithms that utilize random sampling to derive real world numerical results.
These types of algorithms have a number of applications in numerous fields of study including physics, engineering, behavioral sciences, climate forecasting, computer graphics, gaming AI, mathematics, and finance.
Although the applications vary, there is a typical process behind the majority of Monte Carlo methods:
-> First, a distribution of possible inputs is defined.
-> Next, values are generated randomly from the distribution.
-> The values are then fed through some form of deterministic algorithm.
-> And lastly, the results are aggregated over some number of iterations.
In this study, the Monte Carlo process used generates a distribution of aggregate pseudorandom linear price returns summed over a user defined period, then plots standard deviations of the outcomes from the mean outcome generate forecast regions.
The pseudorandom process used in this script relies on a modified Wichmann-Hill pseudorandom number generator (PRNG) algorithm.
Wichmann-Hill is a hybrid generator that uses three linear congruential generators (LCGs) with different prime moduli.
Each LCG within the generator produces an independent, uniformly distributed number between 0 and 1.
The three generated values are then summed and modulo 1 is taken to deliver the final uniformly distributed output.
Because of its long cycle length, Wichmann-Hill is a fantastic generator to use on TV since it's extremely unlikely that you'll ever see a cycle repeat.
The resulting pseudorandom output from this generator has a minimum repetition cycle length of 6,953,607,871,644.
Fun fact: Wichmann-Hill is a widely used PRNG in various software applications. For example, Excel 2003 and later uses this algorithm in its RAND function, and it was the default generator in Python up to v2.2.
The generation algorithm in this script takes the Wichmann-Hill algorithm, and uses a multi-stage transformation process to generate the results.
First, a parent seed is selected. This can either be a fixed value, or a dynamic value.
The dynamic parent value is produced by taking advantage of Pine's timenow variable behavior. It produces a variable parent seed by using a frozen ratio of timenow/time.
Because timenow always reflects the current real time when frozen and the time variable reflects the chart's beginning time when frozen, the ratio of these values produces a new number every time the cache updates.
After a parent seed is selected, its value is then fed through a uniformly distributed seed array generator, which generates multiple arrays of pseudorandom "children" seeds.
The seeds produced in this step are then fed through the main generators to produce arrays of pseudorandom simulated outcomes, and a pseudorandom series to compare with the real series.
The main generators within this script are designed to (at least somewhat) model the stochastic nature of financial time series data.
The first step in this process is to transform the uniform outputs of the Wichmann-Hill into outputs that are normally distributed.
In this script, the transformation is done using an estimate of the normal distribution quantile function.
Quantile functions, otherwise known as percent-point or inverse cumulative distribution functions, specify the value of a random variable such that the probability of the variable being within the value's boundary equals the input probability.
The quantile equation for a normal probability distribution is μ + σ(√2)erf^-1(2(p - 0.5)) where μ is the mean of the distribution, σ is the standard deviation, erf^-1 is the inverse Gauss error function, and p is the probability.
Because erf^-1() does not have a simple, closed form interpretation, it must be approximated.
To keep things lightweight in this approximation, I used a truncated Maclaurin Series expansion for this function with precomputed coefficients and rolled out operations to avoid nested looping.
This method provides a decent approximation of the error function without completely breaking floating point limits or sucking up runtime memory.
Note that there are plenty of more robust techniques to approximate this function, but their memory needs very. I chose this method specifically because of runtime favorability.
To generate a pseudorandom approximately normally distributed variable, the uniformly distributed variable from the Wichmann-Hill algorithm is used as the input probability for the quantile estimator.
Now from here, we get a pretty decent output that could be used itself in the simulation process. Many Monte Carlo simulations and random price generators utilize a normal variable.
However, if you compare the outputs of this normal variable with the actual returns of the real time series, you'll find that the variability in shocks (random changes) doesn't quite behave like it does in real data.
This is because most real financial time series data is more complex. Its distribution may be approximately normal at times, but the variability of its distribution changes over time due to various underlying factors.
In light of this, I believe that returns behave more like a convoluted product distribution rather than just a raw normal.
So the next step to get our procedurally generated returns to more closely emulate the behavior of real returns is to introduce more complexity into our model.
Through experimentation, I've found that a return series more closely emulating real returns can be generated in a three step process:
-> First, generate multiple independent, normally distributed variables simultaneously.
-> Next, apply pseudorandom weighting to each variable ranging from -1 to 1, or some limits within those bounds. This modulates each series to provide more variability in the shocks by producing product distributions.
-> Lastly, add the results together to generate the final pseudorandom output with a convoluted distribution. This adds variable amounts of constructive and destructive interference to produce a more "natural" looking output.
In this script, I use three independent normally distributed variables multiplied by uniform product distributed variables.
The first variable is generated by multiplying a normal variable by one uniformly distributed variable. This produces a bit more tailedness (kurtosis) than a normal distribution, but nothing too extreme.
The second variable is generated by multiplying a normal variable by two uniformly distributed variables. This produces moderately greater tails in the distribution.
The third variable is generated by multiplying a normal variable by three uniformly distributed variables. This produces a distribution with heavier tails.
For additional control of the output distributions, the uniform product distributions are given optional limits.
These limits control the boundaries for the absolute value of the uniform product variables, which affects the tails. In other words, they limit the weighting applied to the normally distributed variables in this transformation.
All three sets are then multiplied by user defined amplitude factors to adjust presence, then added together to produce our final pseudorandom return series with a convoluted product distribution.
Once we have the final, more "natural" looking pseudorandom series, the values are recursively summed over the forecast period to generate a simulated result.
This process of generation, weighting, addition, and summation is repeated over the user defined number of simulations with different seeds generated from the parent to produce our array of initial simulated outcomes.
After the initial simulation array is generated, the max, min, mean and standard deviation of this array are calculated, and the values are stored in holding arrays on each iteration to be called upon later.
Reference difference series and price values are also stored in holding arrays to be used in our comparison plots.
In this script, I use a linear model with simple returns rather than compounding log returns to generate the output.
The reason for this is that in generating outputs this way, we're able to run our simulations recursively from the beginning of the chart, then apply scaling and anchoring post-process.
This allows a greater conservation of runtime memory than the alternative, making it more suitable for doing longer forecasts with heavier amounts of simulations in TV's runtime environment.
From our starting time, the previous bar's price, volatility, and optional drift (expected return) are factored into our holding arrays to generate the final forecast parameters.
After these parameters are computed, the range forecast is produced.
The basis value for the ranges is the mean outcome of the simulations that were run.
Then, quarter standard deviations of the simulated outcomes are added to and subtracted from the basis up to 3σ to generate the forecast ranges.
All of these values are plotted and colorized based on their theoretical probability density. The most likely areas are the warmest colors, and least likely areas are the coolest colors.
An information panel is also displayed at the starting time which shows the starting time and price, forecast type, parent seed value, simulations run, forecast bars, total drift, mean, standard deviation, max outcome, min outcome, and bars remaining.
The interesting thing about simulated outcomes is that although the probability distribution of each simulation is not normal, the distribution of different outcomes converges to a normal one with enough steps.
In light of this, the probability density of outcomes is highest near the initial value + total drift, and decreases the further away from this point you go.
This makes logical sense since the central path is the easiest one to travel.
Given the ever changing state of markets, I find this tool to be best suited for shorter term forecasts.
However, if the movements of price are expected to remain relatively stable, longer term forecasts may be equally as valid.
There are many possible ways for users to apply this tool to their analysis setups. For example, the forecast ranges may be used as a guide to help users set risk targets.
Or, the generated levels could be used in conjunction with other indicators for meaningful confluence signals.
More advanced users could even extrapolate the functions used within this script for various purposes, such as generating pseudorandom data to test systems on, perform integration and approximations, etc.
These are just a few examples of potential uses of this script. How you choose to use it to benefit your trading, analysis, and coding is entirely up to you.
If nothing else, I think this is a pretty neat script simply for the novelty of it.
----------
How To Use:
When you first add the script to your chart, you will be prompted to confirm the starting date and time, number of bars to forecast, number of simulations to run, and whether to include drift assumption.
You will also be prompted to confirm the forecast type. There are two types to choose from:
-> End Result - This uses the values from the end of the simulation throughout the forecast interval.
-> Developing - This uses the values that develop from bar to bar, providing a real-time outlook.
You can always update these settings after confirmation as well.
Once these inputs are confirmed, the script will boot up and automatically generate the forecast in a separate pane.
Note that if there is no bar of data at the time you wish to start the forecast, the script will automatically detect use the next available bar after the specified start time.
From here, you can now control the rest of the settings.
The "Seeding Settings" section controls the initial seed value used to generate the children that produce the simulations.
In this section, you can control whether the seed is a fixed value, or a dynamic one.
Since selecting the dynamic parent option will change the seed value every time you change the settings or refresh your chart, there is a "Regenerate" input built into the script.
This input is a dummy input that isn't connected to any of the calculations. The purpose of this input is to force an update of the dynamic parent without affecting the generator or forecast settings.
Note that because we're running a limited number of simulations, different parent seeds will typically yield slightly different forecast ranges.
When using a small number of simulations, you will likely see a higher amount of variance between differently seeded results because smaller numbers of sampled simulations yield a heavier bias.
The more simulations you run, the smaller this variance will become since the outcomes become more convergent toward the same distribution, so the differences between differently seeded forecasts will become more marginal.
When using a dynamic parent, pay attention to the dispersion of ranges.
When you find a set of ranges that is dispersed how you like with your configuration, set your fixed parent value to the parent seed that shows in the info panel.
This will allow you to replicate that dispersion behavior again in the future.
An important thing to note when settings alerts on the plotted levels, or using them as components for signals in other scripts, is to decide on a fixed value for your parent seed to avoid minor repainting due to seed changes.
When the parent seed is fixed, no repainting occurs.
The "Amplitude Settings" section controls the amplitude coefficients for the three differently tailed generators.
These amplitude factors will change the difference series output for each simulation by controlling how aggressively each series moves.
When "Adjust Amplitude Coefficients" is disabled, all three coefficients are set to 1.
Note that if you expect volatility to significantly diverge from its historical values over the forecast interval, try experimenting with these factors to match your anticipation.
The "Weighting Settings" section controls the weighting boundaries for the three generators.
These weighting limits affect how tailed the distributions in each generator are, which in turn affects the final series outputs.
The maximum absolute value range for the weights is . When "Limit Generator Weights" is disabled, this is the range that is automatically used.
The last set of inputs is the "Display Settings", where you can control the visual outputs.
From here, you can select to display either "Forecast" or "Difference Comparison" via the "Output Display Type" dropdown tab.
"Forecast" is the type displayed by default. This plots the end result or developing forecast ranges.
There is an option with this display type to show the developing extremes of the simulations. This option is enabled by default.
There's also an option with this display type to show one of the simulated price series from the set alongside actual prices.
This allows you to visually compare simulated prices alongside the real prices.
"Difference Comparison" allows you to visually compare a synthetic difference series from the set alongside the actual difference series.
This display method is primarily useful for visually tuning the amplitude and weighting settings of the generators.
There are also info panel settings on the bottom, which allow you to control size, colors, and date format for the panel.
It's all pretty simple to use once you get the hang of it. So play around with the settings and see what kinds of forecasts you can generate!
----------
ADDITIONAL NOTES & DISCLAIMERS
Although I've done a number of things within this script to keep runtime demands as low as possible, the fact remains that this script is fairly computationally heavy.
Because of this, you may get random timeouts when using this script.
This could be due to either random drops in available runtime on the server, using too many simulations, or running the simulations over too many bars.
If it's just a random drop in runtime on the server, hide and unhide the script, re-add it to the chart, or simply refresh the page.
If the timeout persists after trying this, then you'll need to adjust your settings to a less demanding configuration.
Please note that no specific claims are being made in regards to this script's predictive accuracy.
It must be understood that this model is based on randomized price generation with assumed constant drift and dispersion from historical data before the starting point.
Models like these not consider the real world factors that may influence price movement (economic changes, seasonality, macro-trends, instrument hype, etc.), nor the changes in sample distribution that may occur.
In light of this, it's perfectly possible for price data to exceed even the most extreme simulated outcomes.
The future is uncertain, and becomes increasingly uncertain with each passing point in time.
Predictive models of any type can vary significantly in performance at any point in time, and nobody can guarantee any specific type of future performance.
When using forecasts in making decisions, DO NOT treat them as any form of guarantee that values will fall within the predicted range.
When basing your trading decisions on any trading methodology or utility, predictive or not, you do so at your own risk.
No guarantee is being issued regarding the accuracy of this forecast model.
Forecasting is very far from an exact science, and the results from any forecast are designed to be interpreted as potential outcomes rather than anything concrete.
With that being said, when applied prudently and treated as "general case scenarios", forecast models like these may very well be potentially beneficial tools to have in the arsenal.
String Manipulation Framework [PineCoders FAQ]█ OVERVIEW
This script provides string manipulation functions to help Pine coders.
█ FUNCTIONS PROVIDED
f_strLeft(_str, _n)
Function returning the leftmost `_n` characters in `_str`.
f_strRight(_str, _n)
Function returning the rightmost `_n` characters in `_str`.
f_strMid(_str, _from, _to)
Function returning the substring of `_str` from character position `_from` to `_to` inclusively.
f_strLeftOf(_str, _of)
Function returning the sub-string of `_str` to the left of the `_of` separating character.
f_strRightOf(_str, _of)
Function returning the sub-string of `_str` to the right of the `_of` separating character.
f_strCharPos(_str, _chr)
Function returning the position of the first occurrence of `_chr` in `_str`, where the first character position is 0. Returns -1 if the character is not found.
f_strReplace(_src, _pos, _str)
Function that replaces a character at position `_pos` in the `_src` string with the `_str` character or string.
f_tickFormat()
Function returning a format string usable with `tostring()` to round a value to the symbol's tick precision.
f_tostringPad(_val, _fmt)
Function returning a string representation of a numeric `_val` using a special `_fmt` string allowing all strings to be of the same width, to help align columns of values.
`f_tostringPad()`
Using the functions should be straightforward, but `f_tostringPad()` requires more explanations. Its purpose is to help coders produce columns of fixed-width string representations of numbers which can be used to produce columns of numbers that vertically align neatly in labels, something that comes in handy when, for example, you need to center columns, yet still produce numbers of various lengths that nonetheless align.
While the formatting string used with this function resembles the one used in tostring() , it has a few additional characteristics:
• The question mark (" ? ") is used to indicate that padding is needed.
• If negative numbers must be handled by the function, the first character of the formatting string must be a minus sign ("-"),
otherwise the unary minus sign of negative numbers will be stripped out.
• You will produce more predictable results by using "0" rather than "#" in the formatting string.
You can experiment with `f_tostringPad()` formatting strings by changing the one used in the script's inputs and see the results on the chart.
These are some valid examples of formatting strings that can be used with `f_tostringPad()`:
"???0": forces strings to be four units wide, in all-positive "int" format.
"-???0": forces strings to be four units wide, plus room for a unary minus sign in the first position, in "int" format.
"???0.0": forces strings to be four units wide to the left of the point, all-positive, with a decimal point and then a mantissa rounded to a single digit.
"-???0.0?": same as above, but adds a unary minus sign for negative values, and adds a space after the single-digit mantissa.
"?????????0.0": forces the left part of the float to occupy the space of 10 digits, with a decimal point and then a mantissa rounded to a single digit.
█ CHART
The information displayed by this indicator uses the values in the script's Inputs, so you can use them to play around.
The chart shows the following information:
• Column 0 : The numeric input values in a centered column, converted to strings using tostring() without a formatting argument.
• Column 1 : Shows the values formatted using `f_tostringPad()` with the formatting string from the inputs.
• Column 2 : Shows the values formatted using `f_tostringPad()` but with only the part of the formatting string left of the decimal point, if it contains one.
• Column 3 : Shows the values formatted using `f_tostringPad()` but with the part of the formatting string left of the decimal point,
to which is added the right part of the `f_tostringPad()` formatting string, to obtain the precision in ticks of the symbol the chart is on.
• Column 4 : Shows the result of using the other string manipulation functions in the script on the source string supplied in the inputs.
It also demonstrates how to split up a label in two distinct parts so that you can vertically align columns when the leftmost part contains strings with varying lengths.
You will see in our code how we construct this column in two steps.
█ LIMITATIONS
The Pine runtime is optimized for number crunching. Too many string manipulations will take a toll on the performance of your scripts, as can readily be seen with the running time of this script. To minimize the impact of using string manipulation functions in your scripts, consider limiting their calculation to the first or last bar of the dataset when possible. This can be achieved by using the var keyword when declaring variables containing the result of your string manipulations, or by enclosing blocks of code in if blocks using barstate.isfirst or barstate.islast .
█ NOTES
To understand the challenges we face when trying to align strings vertically, it is useful to know that:
• As is the case in many other places in the TadingView UI and other docs, the Pine runtime uses the MS Trebuchet font to display label text.
• Trebuchet uses proportionally-spaced letters (a "W" takes more horizontal space than an "I"), but fixed-space digits (a "1" takes the same horizontal space as a "3").
Digits all use a figure space width, and it is this property that allows us to align numbers vertically.
The fact that letters are proportionally spaced is the reason why we can't vertically align columns using a "legend" + ":" `+ value structure when the "legend" part varies in width.
• The unary minus sign is the width of a punctuation space . We use this property to pad the beginning of numbers
when you use a "-" as the first character of the `f_tostringPad()` formatting string.
Our script was written using the PineCoders Coding Conventions for Pine .
The description was formatted using the techniques explained in the How We Write and Format Script Descriptions PineCoders publication.
█ THANKS
Thanks to LonesomeTheBlue for the `f_strReplace()` function.
Look first. Then leap.
Money Flow Profile [LuxAlgo]The Money Flow Profile is a charting tool that measures the traded volume or the money flow at all price levels on the market over a specified time period and highlights the relationship between the price of a given asset and the willingness of traders to either buy or sell it, allowing traders to reveal dominant and/or significant price levels and to analyze the trading activity of a particular user-selected range.
This tool combines a volume/money flow profile, a sentiment profile, and price levels, where the right side of the profile highlights the distribution of the traded activity/money flow at different price levels, the left side of the profile highlights the market sentiment at those price levels, and in the middle the price levels.
🔶 USAGE
A volume/money flow profile is an advanced charting tool that displays the traded volume/money flow at different price levels over a specific period. It helps traders visualize where the majority of trading activity/money flow has occurred.
A sentiment profile is a difference between buy and sell volume/money flow aiming to highlight the sentiment/dominance at specific price levels.
Each row of the profile presents figures on volume and money flow specific to price levels.
High volume/money flow nodes indicate areas of high activity and are likely to act as support or resistance in the future. They attract price and try to hold it there. Conversely, low-volume nodes are areas with low trading activity, that are less subject to get revisited by the price. The market often bounces right over these levels, not staying for long. The "Profile Heatmap" option of the script helps to better emphasize the trading activity within each areas.
By measuring the traded activity at each price level the script presents an ability to highlight the consolidation zones, in other words, highlights accumulation and distribution zones. When the price moves toward one end of the consolidation and volume pick up, it can foreshadow a potential breakout.
Level of Significance, Point of Control, Highest Sentiment Zone, and Profile Price levels are some of the other profile-related options available with the script.
🔶 SETTINGS
The script takes into account user-defined parameters and plots the profiles, where detailed usage for each user-defined input parameter in indicator settings is provided with the related input's tooltip.
🔹 Profile Generic Settings
Lookback Length / Fixed Range: Sets the lookback length.
Profile Source: Sets the profile source, Volume, or Money Flow.
🔹 Profile Presentation Settings
Volume/Money Flow Profile: Toggles the visibility of the Volume/Money Flow Profile.
High Traded Nodes: Threshold and Color option for high traded nodes.
Average Traded Nodes: Color option for average traded nodes.
Low Traded Nodes: Threshold and Color option for low traded nodes.
🔹 Sentiment Profile Settings
Sentiment Profile: Toggles the visibility of the Sentiment Profile.
Sentiment Polarity Method: Sets the method used to calculate the up/down volume/money flow.
Bullish Nodes: Color option for Bullish Nodes.
Bearish Nodes: Color option for Bearish Nodes.
🔹 Profile Heatmap Settings
Profile Heatmap: Toggles the visibility of the profile heatmap.
Heatmap Source: Sets the source of the profile heatmap, Volume/Money Flow Profile, or Sentiment Profile.
Heatmap Transparency: Control the transparency of the profile heatmap.
🔹 Other Presentation Settings
Level of Significance: Toggles the visibility of the level of significance line/zone.
Consolidation Zones: Toggles the visibility of the consolidation zones.
Consolidation Threshold, Color: Sets the threshold value and zone color.
Highest Sentiment Zone: Toggles the visibility of the highest bullish or bearish sentiment zone.
Profile Price Levels, Color, Size: Toggles the visibility of the profile price levels, and sets the color and the size of the level labels.
Profile Range Background Fill: Toggles the visibility of the profiles range.
🔹 Other Settings
Number of Rows: Specify how many rows each profile histogram will have.
Profile Width %: Alters the width of the rows in the histogram, relative to the profile length
Profile Text Size: Alters the size of the text. Setting to Auto will keep the text within the box limits.
Profile Horizontal Offset: Enables to move profile in the horizontal axis.
🔶 RELATED SCRIPTS
Liquidity-Sentiment-Profile
Swing-Volume-Profiles
For more and other conceptual scripts you are kindly invited to visit LuxAlgo-Scripts .
Bitcoin Macro Trend Map [Ox_kali]
## Introduction
__________________________________________________________________________________
The “Bitcoin Macro Trend Map” script is designed to provide a comprehensive analysis of Bitcoin’s macroeconomic trends. By leveraging a unique combination of Bitcoin-specific macroeconomic indicators, this script helps traders identify potential market peaks and troughs with greater accuracy. It synthesizes data from multiple sources to offer a probabilistic view of market excesses, whether overbought or oversold conditions.
This script offers significant value for the following reasons:
1. Holistic Market Analysis : It integrates a diverse set of indicators that cover various aspects of the Bitcoin market, from investor sentiment and market liquidity to mining profitability and network health. This multi-faceted approach provides a more complete picture of the market than relying on a single indicator.
2. Customization and Flexibility : Users can customize the script to suit their specific trading strategies and preferences. The script offers configurable parameters for each indicator, allowing traders to adjust settings based on their analysis needs.
3. Visual Clarity : The script plots all indicators on a single chart with clear visual cues. This includes color-coded indicators and background changes based on market conditions, making it easy for traders to quickly interpret complex data.
4. Proven Indicators : The script utilizes well-established indicators like the EMA, NUPL, PUELL Multiple, and Hash Ribbons, which are widely recognized in the trading community for their effectiveness in predicting market movements.
5. A New Comprehensive Indicator : By integrating background color changes based on the aggregate signals of various indicators, this script essentially creates a new, comprehensive indicator tailored specifically for Bitcoin. This visual representation provides an immediate overview of market conditions, enhancing the ability to spot potential market reversals.
Optimal for use on timeframes ranging from 1 day to 1 week , the “Bitcoin Macro Trend Map” provides traders with actionable insights, enhancing their ability to make informed decisions in the highly volatile Bitcoin market. By combining these indicators, the script delivers a robust tool for identifying market extremes and potential reversal points.
## Key Indicators
__________________________________________________________________________________
Macroeconomic Data: The script combines several relevant macroeconomic indicators for Bitcoin, such as the 10-month EMA, M2 money supply, CVDD, Pi Cycle, NUPL, PUELL, MRVR Z-Scores, and Hash Ribbons (Full description bellow).
Open Source Sources: Most of the scripts used are sourced from open-source projects that I have modified to meet the specific needs of this script.
Recommended Timeframes: For optimal performance, it is recommended to use this script on timeframes ranging from 1 day to 1 week.
Objective: The primary goal is to provide a probabilistic solution to identify market excesses, whether overbought or oversold points.
## Originality and Purpose
__________________________________________________________________________________
This script stands out by integrating multiple macroeconomic indicators into a single comprehensive tool. Each indicator is carefully selected and customized to provide insights into different aspects of the Bitcoin market. By combining these indicators, the script offers a holistic view of market conditions, helping traders identify potential tops and bottoms with greater accuracy. This is the first version of the script, and additional macroeconomic indicators will be added in the future based on user feedback and other inputs.
## How It Works
__________________________________________________________________________________
The script works by plotting each macroeconomic indicator on a single chart, allowing users to visualize and interpret the data easily. Here’s a detailed look at how each indicator contributes to the analysis:
EMA 10 Monthly: Uses an exponential moving average over 10 monthly periods to signal bullish and bearish trends. This indicator helps identify long-term trends in the Bitcoin market by smoothing out price fluctuations to reveal the underlying trend direction.Moving Averages w/ 18 day/week/month.
Credit to @ryanman0
M2 Money Supply: Analyzes the evolution of global money supply, indicating market liquidity conditions. This indicator tracks the changes in the total amount of money available in the economy, which can impact Bitcoin’s value as a hedge against inflation or economic instability.
Credit to @dylanleclair
CVDD (Cumulative Value Days Destroyed): An indicator based on the cumulative value of days destroyed, useful for identifying market turning points. This metric helps assess the Bitcoin market’s health by evaluating the age and value of coins that are moved, indicating potential shifts in market sentiment.
Credit to @Da_Prof
Pi Cycle: Uses simple and exponential moving averages to detect potential sell points. This indicator aims to identify cyclical peaks in Bitcoin’s price, providing signals for potential market tops.
Credit to @NoCreditsLeft
NUPL (Net Unrealized Profit/Loss): Measures investors’ unrealized profit or loss to signal extreme market levels. This indicator shows the net profit or loss of Bitcoin holders as a percentage of the market cap, helping to identify periods of significant market optimism or pessimism.
Credit to @Da_Prof
PUELL Multiple: Assesses mining profitability relative to historical averages to indicate buying or selling opportunities. This indicator compares the daily issuance value of Bitcoin to its yearly average, providing insights into when the market is overbought or oversold based on miner behavior.
Credit to @Da_Prof
MRVR Z-Scores: Compares market value to realized value to identify overbought or oversold conditions. This metric helps gauge the overall market sentiment by comparing Bitcoin’s market value to its realized value, identifying potential reversal points.
Credit to @Pinnacle_Investor
Hash Ribbons: Uses hash rate variations to signal buying opportunities based on miner capitulation and recovery. This indicator tracks the health of the Bitcoin network by analyzing hash rate trends, helping to identify periods of miner capitulation and subsequent recoveries as potential buying opportunities.
Credit to @ROBO_Trading
## Indicator Visualization and Interpretation
__________________________________________________________________________________
For each horizontal line representing an indicator, a legend is displayed on the right side of the chart. If the conditions are positive for an indicator, it will turn green, indicating the end of a bearish trend. Conversely, if the conditions are negative, the indicator will turn red, signaling the end of a bullish trend.
The background color of the chart changes based on the average of green or red indicators. This parameter is configurable, allowing adjustment of the threshold at which the background color changes, providing a clear visual indication of overall market conditions.
## Script Parameters
__________________________________________________________________________________
The script includes several configurable parameters to customize the display and behavior of the indicators:
Color Style:
Normal: Default colors.
Modern: Modern color style.
Monochrome: Monochrome style.
User: User-customized colors.
Custom color settings for up trends (Up Trend Color), down trends (Down Trend Color), and NaN (NaN Color)
Background Color Thresholds:
Thresholds: Settings to define the thresholds for background color change.
Low/High Red Threshold: Low and high thresholds for bearish trends.
Low/High Green Threshold: Low and high thresholds for bullish trends.
Indicator Display:
Options to show or hide specific indicators such as EMA 10 Monthly, CVDD, Pi Cycle, M2 Money, NUPL, PUELL, MRVR Z-Scores, and Hash Ribbons.
Specific Indicator Settings:
EMA 10 Monthly: Options to customize the period for the exponential moving average calculation.
M2 Money: Aggregation of global money supply data.
CVDD: Adjustments for value normalization.
Pi Cycle: Settings for simple and exponential moving averages.
NUPL: Thresholds for unrealized profit/loss values.
PUELL: Adjustments for mining profitability multiples.
MRVR Z-Scores: Settings for overbought/oversold values.
Hash Ribbons: Options for hash rate moving averages and capitulation/recovery signals.
## Conclusion
__________________________________________________________________________________
The “Bitcoin Macro Trend Map” by Ox_kali is a tool designed to analyze the Bitcoin market. By combining several macroeconomic indicators, this script helps identify market peaks and troughs. It is recommended to use it on timeframes from 1 day to 1 week for optimal trend analysis. The scripts used are sourced from open-source projects, modified to suit the specific needs of this analysis.
## Notes
__________________________________________________________________________________
This is the first version of the script and it is still in development. More indicators will likely be added in the future. Feedback and comments are welcome to improve this tool.
## Disclaimer:
__________________________________________________________________________________
Please note that the Open Interest liquidation map is not a guarantee of future market performance and should be used in conjunction with proper risk management. Always ensure that you have a thorough understanding of the indicator’s methodology and its limitations before making any investment decisions. Additionally, past performance is not indicative of future results.
High Volume AlertThe High Volume Alert Script is developed for all traders focusing on volume analysis in their trading strategies, providing alerts for unusually high trading volumes during specified trading sessions.
Functionality:
Volume Moving Average Calculation:
Average Volume = Moving Average(Volume) = Sum of last the x last candles Volume
Where n is the user-defined period for the moving average calculation (denoted as movingaverageinput in the script. This moving average serves as the baseline to compare current volume levels against historical averages.
High Volume Detection:
HighVolume = CurrentVolume >= (MA(Volume) x HighVolumeRatio)
Here, HighVolumeRatio is a user-defined multiplier that sets the threshold for what is considered high volume. If the current volume exceeds this threshold (the product of the moving average of volume and the HighVolumeRatio ), the script identifies this as a high-volume event.
Session Filtering:
The script further refines these alerts by ensuring they only trigger during the specified trading session, enhancing relevance for traders interested in specific market hours. This session is defined by the sess and timezone parameters.
Visualisation and Alerts:
If high volume is detected (HighVolume = True), the script colors the volume bar with the highVolumeColor . If the option is selected, it also changes the color of the candlestick to either highVolumeCandleColorUp (for bullish candles) or highVolumeCandleColorDown (for bearish candles), depending on the price movement within the high-volume period. An alert is generated through the alertcondition function when high volume is detected during the specified session, notifying the trader of potentially significant market activity.
Application in Trading:
This indicator serves traders who prioritize volume as a leading indicator of potential price movement. High trading volumes may indicate the presence of significant market activity, often associated with events like news releases, market openings, or large trades, which can precede price movements.
Originality and Practicality:
This script is self-developed, aiming to fill the gap in automatic ratio adjusted volume alerts within the TradingView environment.
Conclusion:
The High Volume Alert Script is an essential tool for traders who integrate volume analysis into their strategy, offering tailored alerts and visual cues for high volume periods.
Compliance and Limitations:
The script complies with TradingView scripting standards, ensuring no lookahead bias and maintaining real-time data integrity. However, its utility depends on the availability on volume data, and please be aware that forex pairs never offer real volume data, this tool is best used with a exchange traded symbol.
RAINBOW AVERAGES - INDICATOR - (AS) - 1/3
-INTRODUCTION:
This is the first of three scripts I intend to publish using rainbow indicators. This script serves as a groundwork for the other two. It is a RAINBOW MOVING AVERAGES indicator primarily designed for trend detection. The upcoming script will also be an indicator but with overlay=false (below the chart, not on it) and will utilize RAINBOW BANDS and RAINBOW OSCILLATOR. The third script will be a strategy combining all of them.
RAINBOW moving averages can be used in various ways, but this script is mainly intended for trend analysis. It is meant to be used with overlay=true, but if the user wishes, it can be viewed below the chart. To achieve this, you need to change the code from overlay=true to false and turn off the first switch that plots the rainbow on the chart (or simply move the indicator to a new pane below). By doing this, you will be able to see how all four conditions used to detect trends work on the chart. But let's not get ahead of ourselves.
-WHAT IS IT:
In its simplest form, this indicator uses 10 moving averages colored like a rainbow. The calculation is as follows:
MA0: This is the main moving average and can be defined with the type (SMA, EMA, RMA, WMA, SINE), length, and price source. However, the second moving average (MA1) is calculated using MA0 as its source, MA2 uses MA1 as the data source, and so on, until the last one, MA9. Hence, there are 10 moving averages. The first moving average is special as all the others derive from it. This indicator has many potential uses, such as entry/exit signals, volatility indication, and stop-loss placement, but for now, we will focus on trend detection.
-TREND DETECTION:
The indicator offers four different background color options based on the user's preference:
0-NONE: No background color is applied as no trend detection tools is being used (boring)
1-CHANGE: The background color is determined by summing the changes of all 10 moving averages (from two bars). If the sum is positive and not falling, the background color is GREEN. If the sum is negative and not rising, the background color is RED. From early testing, it works well for the beginning of a movement but not so much for a lasting trend.
2-RAINBW: The background color is green when all the moving averages are in ascending order, indicating a bullish trend. It is red when all the moving averages are in descending order, indicating a bearish trend. For example, if MA1>MA2>MA3>MA4..., the background color is green. If MA1 threshold, and red indicates width < -threshold.
4-DIRECT: The background color is determined by counting the number of moving averages that are either above or below the input source. If the specified number of moving averages is above the source, the background color is green. If the specified number of moving averages is below the source, the background color is red. If all ten MAs are below the price source, the indicator will show 10, and if all ten MAs are above, it will show -10. The specific value will be set later in the settings (same for 3-TSHOLD variant). This method works well for lasting trends.
Note: If the indicator is turned into a below-chart version, all four color options can be seen as separate indicators.
-PARAMETERS - SETTINGS:
The first line is an on/off switch to plot the skittles indicator (and some info in the tooltip). The second line has already been discussed, which is the background color and the selection of the source (only used for MA0!).
The line "MA1: TYP/LEN" is where we define the parameters of MA0 (important). We choose from the types of moving averages (SMA, EMA, RMA, WMA, SINE) and set the length.
Important Note: It says MA1, but it should be MA0!.
The next line defines whether we want to smooth MA1 (which is actually MA0) and the period for smoothing. When smoothing is turned on, MA0 will be smoothed using a 3-pole super smoother. It's worth noting that although this only applies to MA0, as the other MAs are derived from it, they will also be smoothed.
In the line below, we define the type and length of MAs for MA2 (and other MAs except MA0). The same type and length are used for MA1 to MA9. It's important to remember that these values should be smaller. For example, if we set 55, it means that MA1 is the average of 55 periods of MA0, MA2 will be 55 periods of MA1, and so on. I encourage trying different combinations of MA types as it can be easily adjusted for ur type of trading. RMA looks quirky.
Moving on to the last line, we define some inputs for the background color:
TSH: The threshold value when using 3-TSHOLD-BGC. It's a good idea to change the chart to a pane below for easier adjustment. The default values are based on EURUSD-5M.
BG_DIR: The value that must be crossed or equal to the MA score if using 4-DIRECT-BGC. There are 10 MAs, so the maximum value is also 10. For example, if you set it to 9, it means that at least 9 MAs must be below/above the price for the script to detect a trend. Higher values are recommended as most of the time, this indicator oscillates either around the maximum or minimum value.
-SUMMARY OF SETTINGS:
L1 - PLOT MAs and general info tooltip
L2 - Select the source for MA0 and type of trend detection.
L3 - Set the type and length of MA0 (important).
L4 - Turn smoothing on/off for MA0 and set the period for super smoothing.
L5 - Set the type and length for the rest of the MAs.
L6 - Set values if using 4-DIRECT or 3-TSHOLD for the trend detection.
-OTHERS:
To see trend indicators, you need to turn off the plotting of MAs (first line), and then choose the variant you want for the background color. This will plot it on the chart below.
Keep in mind that M1 int settings stands for MA0 and MA2 for all of the 9 MAs left.
Yes, it may seem more complicated than it actually is. In a nutshell, these are 10 MAs, and each one after MA0 uses the previous one as its source. Plus few conditions for range detection. rest is mainly plots and colors.
There are tooltips to help you with the parameters.
I hope this will be useful to someone. If you have any ideas, feedback, or spot errors in the code, LET ME KNOW.
Stay tuned for the remaining two scripts using skittles indicators and check out my other scripts.
-ALSO:
I'm always looking for ideas for interesting indicators and strategies that I could code, so if you don't know Pinescript, just message me, and I would be glad to write your own indicator/strategy for free, obviously.
-----May the force of the market be with you, and until we meet again,
Quickfingers Luc base scanner - version 2This is my second implementation of a Pine Script Quickfingers Luc (QFL) base scanner that I have published on Trading View. QFL base scanners seek to provide buy signals according to the QFL trading strategy. To profitably trade using this script you should be familiar with the QFL trading strategy, scaling in and out of positions, and money risk management.
Background
All the QFL base identification Pine Scripts that I have inspected to date use a simple candlestick pattern of two lower lows followed by two higher lows to identify a base. Some scripts may combine this with a volume indicator as well. In practice, I found the results of this approach to be somewhat unreliable. The candlestick pattern may identify some significant bases, may identify minor bases (that should not be traded), but at the same time miss other significant bases entirely!
My first QFL base scanner sought to use Pine Script’s built in ta.lowest and ta.highest functions to identify bases and peaks. This approach depended on the time period selected to find the lowest lows and highest highs. This approach can be problematic because significant bases may be formed outside the nominated time period, leading to the identification of minor bases within the time period. I have left the first version of my QFL base scanning script in the Trading View indicators because it uses a different approach to this script that other people may still find useful.
My second version of the QFL base scanner does not use the Pine Script ta.lowest and ta.highest functions, and therefore does not rely on nominating a time period to look back through data.
User inputs
This script steps through the price data to find the following patterns that are used to confirm bases and peaks.
Base – bounce of x% above previous base confirms that base
Peak – fall of y% below previous peak confirms that peak
Buy signal – fall of z% below the base signals a buy signal.
x%, y% and z% are user configurable through the script settings. Small percentages will provide more, but riskier, buy signals; larger percentages will provide fewer, but safer, buy signals.
The script identifies QFL bases and buy signals and marks them on the price chart. These are able to be turned on and off in the script settings. The settings also allow the user to turn on plots for peaks, lowest lows and highest highs. These are not useful for applying the QFL trading strategy, but are calculations used in finding bases and can be useful for the user to understand what the script is doing in the background.
Troubleshooting
If looking at the past script results, you may think that the script is perfectly timing entry points at the bottom of market dips. This is NOT the case. The script is actually showing buy signals when the price falls z% below the PREVIOUS base. The current base is only retrospectively marked some periods later once the reversal is confirmed – a solid line marks a confirmed base in real time; a dotted line retrospectively repaints the line to the actual base. New bases are not tradeable using this script, but a percentage fall from the previous base is – this is the QFL trading strategy.
Pine Script may flag that this script has a repainting issue. Pine Script defines repainting as, “script behavior causing historical vs realtime calculations or plots to behave differently.” In the case of this script, bases are confirmed once the price has bounced x% off the low. The script then repaints a dotted line from the base that has been identified in real time (with a solid line) back to the point in the price data where the base actually occurs. The dotted line only aids in visual identification of the base, and does not impact on the real time identification of bases. A similar repainting issue occurs for identifying peaks. I have identified the lines in the script that cause this repainting. These lines can be commented out without affecting the buy signals generated by the script, but you will also lose the visual pinpointing of historical bases and peaks.
The user may find price charts where they think that the script has not correctly identified a base or peak. Usually, careful measurement will reveal that the price chart has not confirmed a base or peak by moving x% or y% from the previous base or peak respectively.
And before you ask, yes, Trading View alerts work with this script.
Enjoy.
Trend WaveHello Traders!
You know, I can sill remember the first time I started tinkering with Pinescript. As I had no prior programming experience, I learned by experimenting with other open-source scripts on TradingViews Marketplace. Tearing apart and combining interesting scripts to see what the output would be. @ChrisMoody was a huge source of inspiration for learning, and I wanted to thank him, as well as @TheLark for the concept behind this script.
The Trend Wave is based on @ChrisMoody's PPO-PercentileRank-Mkt-Tops-Bottoms , which also happens to be based on @TheLark's TheLark-Laguerre-PPO/ .
Within my experimentation, I found that if I isolate the ppoT & ppoB variables and plot them calculated from extremely small decimals, you can get an extremely fast reacting, mirroring trend detector.
Within the script, you have the ability to plot the background colors based on trend to make it easier to see where crossovers occured, as well as a Mirror Input to view the mirrored version of the script.
-@DayTradingOil
™TradeChartist Fib Extensions™TradeChartist Fib Extensions is a free to use script that helps traders plot Fibonacci Extensions on chart. Even though Trading View has a Fib extensions tool, some traders may prefer a plotting script like this with Fib plot lines extending across the whole of the chart to track historic prices in relation to Fib extensions drawn.
----To draw Fib extensions for uptrend ,
1. Choose a Pivot Low point (LL or a HL) as Pivot 1
2. Choose a Pivot High point (must be higher than Pivot 1) as Pivot 2
3. Choose a Pivot Low point (must be lower than Pivot 2, must be Higher than Pivot 1)
----To draw Fib extensions for downtrend,
1. Choose a Pivot High point (HH or a LH) as Pivot 1
2. Choose a Pivot Low point (must be lower than Pivot 1) as Pivot 2
3. Choose a Pivot High point (must be higher than Pivot 2 and lower than Pivot 1)
Negative extensions of -23.6% and -61.8% fib plots may be useful for some to spot reversals or to set stop losses.
Higher levels can be used if price goes beyond 161.8%
This is a free to use indicator. Give a thumbs up or leave a comment if you like the script
Check my 'Scripts' page to see other published scripts. Get in touch with me if you would like access to my invite-only scripts for a trial before deciding on a paid access for a period of your choice. Half-Yearly, Annual and Lifetime access available on invite-only scripts along with 1hr Team Viewer intro session.
Watermark with dynamic variables [BM]█ OVERVIEW
This indicator allows users to add highly customizable watermark messages to their charts. Perfect for branding, annotation, or displaying dynamic chart information, this script offers advanced customization options including dynamic variables, text formatting, and flexible positioning.
█ CONCEPTS
Watermarks are overlay messages on charts. This script introduces placeholders — special keywords wrapped in % signs — that dynamically replace themselves with chart-related data. These watermarks can enhance charts with context, timestamps, or branding.
█ FEATURES
Dynamic Variables : Replace placeholders with real-time data such as bar index, timestamps, and more.
Advanced Customization : Modify text size, color, background, and alignment.
Multiple Messages : Add up to four independent messages per group, with two groups supported (A and B).
Positioning Options : Place watermarks anywhere on the chart using predefined locations.
Timezone Support : Display timestamps in a preferred timezone with customizable formats.
█ INPUTS
The script offers comprehensive input options for customization. Each Watermark (A and B) contains identical inputs for configuration.
Watermark settings are divided into two levels:
Watermark-Level Settings
These settings apply to the entire watermark group (A/B):
Show Watermark: Toggle the visibility of the watermark group on the chart.
Position: Choose where the watermark group is displayed on the chart.
Reverse Line Order: Enable to reverse the order of the lines displayed in Watermark A.
Message-Level Settings
Each watermark contains up to four configurable messages. These messages can be independently customized with the following options:
Message Content: Enter the custom text to be displayed. You can include placeholders for dynamic data.
Text Size: Select from predefined sizes (Tiny, Small, Normal, Large, Huge) or specify a custom size.
Text Alignment and Colors:
- Adjust the alignment of the text (Left, Center, Right).
- Set text and background colors for better visibility.
Format Time: Enable time formatting for this watermark message and configure the format and timezone. The settings for each message include message content, text size, alignment, and more. Please refer to Formatting dates and times for more details on valid formatting tokens.
█ PLACEHOLDERS
Placeholders are special keywords surrounded by % signs, which the script dynamically replaces with specific chart-related data. These placeholders allow users to insert dynamic content, such as bar information or timestamps, into watermark messages.
Below is the complete list of currently available placeholders:
bar_index , barstate.isconfirmed , barstate.isfirst , barstate.ishistory , barstate.islast , barstate.islastconfirmedhistory , barstate.isnew , barstate.isrealtime , chart.is_heikinashi , chart.is_kagi , chart.is_linebreak , chart.is_pnf , chart.is_range , chart.is_renko , chart.is_standard , chart.left_visible_bar_time , chart.right_visible_bar_time , close , dayofmonth , dayofweek , dividends.future_amount , dividends.future_ex_date , dividends.future_pay_date , earnings.future_eps , earnings.future_period_end_time , earnings.future_revenue , earnings.future_time , high , hl2 , hlc3 , hlcc4 , hour , last_bar_index , last_bar_time , low , minute , month , ohlc4 , open , second , session.isfirstbar , session.isfirstbar_regular , session.islastbar , session.islastbar_regular , session.ismarket , session.ispostmarket , session.ispremarket , syminfo.basecurrency , syminfo.country , syminfo.currency , syminfo.description , syminfo.employees , syminfo.expiration_date , syminfo.industry , syminfo.main_tickerid , syminfo.mincontract , syminfo.minmove , syminfo.mintick , syminfo.pointvalue , syminfo.prefix , syminfo.pricescale , syminfo.recommendations_buy , syminfo.recommendations_buy_strong , syminfo.recommendations_date , syminfo.recommendations_hold , syminfo.recommendations_sell , syminfo.recommendations_sell_strong , syminfo.recommendations_total , syminfo.root , syminfo.sector , syminfo.session , syminfo.shareholders , syminfo.shares_outstanding_float , syminfo.shares_outstanding_total , syminfo.target_price_average , syminfo.target_price_date , syminfo.target_price_estimates , syminfo.target_price_high , syminfo.target_price_low , syminfo.target_price_median , syminfo.ticker , syminfo.tickerid , syminfo.timezone , syminfo.type , syminfo.volumetype , ta.accdist , ta.iii , ta.nvi , ta.obv , ta.pvi , ta.pvt , ta.tr , ta.vwap , ta.wad , ta.wvad , time , time_close , time_tradingday , timeframe.isdaily , timeframe.isdwm , timeframe.isintraday , timeframe.isminutes , timeframe.ismonthly , timeframe.isseconds , timeframe.isticks , timeframe.isweekly , timeframe.main_period , timeframe.multiplier , timeframe.period , timenow , volume , weekofyear , year
█ HOW TO USE
1 — Add the Script:
Apply "Watermark with dynamic variables " to your chart from the TradingView platform.
2 — Configure Inputs:
Open the script settings by clicking the gear icon next to the script's name.
Customize visibility, message content, and appearance for Watermark A and Watermark B.
3 — Utilize Placeholders:
Add placeholders like %bar_index% or %timenow% in the "Watermark - Message" fields to display dynamic data.
Empty lines in the message box are reflected on the chart, allowing you to shift text up or down.
Using \n in the message box translates to a new line on the chart.
4 — Preview Changes:
Adjust settings and view updates in real-time on your chart.
█ EXAMPLES
Branding
DodgyDD's charts
Debugging
█ LIMITATIONS
Only supports variables defined within the script.
Limited to four messages per watermark.
Visual alignment may vary across different chart resolutions or zoom levels.
Placeholder parsing relies on correct input formatting.
█ NOTES
This script is designed for users seeking enhanced chart annotation capabilities. It provides tools for dynamic, customizable watermarks but is not a replacement for chart objects like text labels or drawings. Please ensure placeholders are properly formatted for correct parsing.
Additionally, this script can be a valuable tool for Pine Script developers during debugging . By utilizing dynamic placeholders, developers can display real-time values of variables and chart data directly on their charts, enabling easier troubleshooting and code validation.
Volume Profile with Node Detection [LuxAlgo]The Volume Profile with Node Detection is a charting tool that allows visualizing the distribution of traded volume across specific price levels and highlights significant volume nodes or clusters of volume nodes that traders may find relevant in utilizing in their trading strategies.
🔶 USAGE
The volume profile component of the script serves as the foundation for node detection while encompassing all the essential features expected from a volume profile. See the sub-sections below for more detailed information about the indicator components and their usage.
🔹 Peak Volume Node Detection
A volume peak node is identified when the volume profile nodes for the N preceding and N succeeding nodes are lower than that of the evaluated one.
Displaying peak volume nodes along with their surrounding N nodes (Zones or Clusters) helps visualize the range, typically representing consolidation zones in the market. This feature enables traders to identify areas where trading activity has intensified, potentially signaling periods of price consolidation or indecision among market participants.
🔹 Trough Volume Node Detection
A volume trough node is identified when the volume profile nodes for the N preceding and N succeeding nodes are higher than that of the evaluated one.
🔹 Highest and Lowest Volume Nodes
Both the highest and lowest volume areas play significant roles in trading. The highest volume areas typically represent zones of strong price acceptance, where a significant amount of trading activity has occurred. On the other hand, the lowest volume areas signify price levels with minimal trading activity, often indicating zones of price rejection or areas where market participants have shown less interest.
🔹 Volume profile
Volume profile is calculated based on the volume of trades that occur at various price levels within a specified timeframe. It divides the price range into discrete price intervals, typically known as "price buckets" or "price bars," and then calculates the total volume of trades that occur at each price level within those intervals. This information is then presented graphically as a histogram or profile, where the height of each bar represents the volume of trades that occurred at that particular price level.
🔶 SETTINGS
🔹 Volume Nodes
Volume Peaks: Toggles the visibility of either the "Peaks" or "Clusters" on the chart, depending on the specified percentage for detection.
Node Detection Percent %: Specifies the percentage for the Volume Peaks calculation.
Volume Troughs: Toggles the visibility of either the "Troughs" or "Clusters" on the chart, depending on the specified percentage for detection.
Node Detection Percent %: Specifies the percentage for the Volume Troughs calculation.
Volume Node Threshold %: A threshold value specified as a percentage is utilized to detect peak/trough volume nodes. If a value is set, the detection will disregard volume node values lower than the specified threshold.
Highest Volume Nodes: Toggles the visibility of the highest nodes for the specified count.
Lowest Volume Nodes: Toggles the visibility of the lowest nodes for the specified count.
🔹 Volume Profile - Components
Volume Profile: Toggles the visibility of the volume profile with either classical display or gradient display.
Value Area Up / Down: Color customization option for the volume nodes within the value area of the profile.
Profile Up / Down Volume: Color customization option for the volume nodes outside of the value area of the profile.
Point of Control: Toggles the visibility of the point of control, allowing selection between "developing" or "regular" modes. Sets the color and width of the point of control line accordingly.
Value Area High (VAH): Toggles the visibility of the value area high level and allows customization of the line color.
Value Area Low (VAL): Toggles the visibility of the value area low level and allows customization of the line color.
Profile Price Labels: Toggles the visibility of the Profile Price Levels and allows customization of the text size of the levels.
🔹 Volume Profile - Display Settings
Profile Lookback Length: Specifies the length of the profile lookback period.
Value Area (%): Specifies the percentage for calculating the value area.
Profile Placement: Specify where to display the profile.
Profile Number of Rows: Specify the number of rows the profile will have.
Profile Width %: Adjusts the width of the rows in the profile relative to the profile range.
Profile Horizontal Offset: Adjusts the horizontal offset of the profile when it is selected to be displayed on the right side of the chart.
Value Area Background: Toggles the visibility of the value area background and allows customization of the fill color.
Profile Background: Toggles the visibility of the profile background and allows customization of the fill color.
🔶 RELATED SCRIPTS
Supply-Demand-Profiles
Liquidity-Sentiment-Profile
Thanks to our community for recommending this script. For more conceptual scripts and related content, we welcome you to explore by visiting >>> LuxAlgo-Scripts .
Bond Yield SpreadThe Bond Yield Spread Script is developed for forex traders, offering an automated tool to calculate the bond yield spread between two countries associated with the forex pair displayed on the chart.
Functionality:
The script starts by identifying the base and quote currencies of the current forex pair and aligns them with their corresponding national bond symbols based on user-selected maturity, with options ranging from 01Y to 30Y. It calculates the yield spread by subtracting the bond yield associated with the quote country from that of the base country, following the formula:
Yield Spread = Yield(Base Country) − Yield(Quote Country)
which is then displayed as a plot line on the chart.
This script relies solely on TradingView's internal yield symbols, with the following calculation:
"currency" => "first two letters" + maturity
And maturity, in this case, is the value that is configured in the indicator settings, for example:
"EUR" => "EU" + "02Y" will result in EU02Y -> which will be used in the formula, depending on the quote or base currency.
Application in Trading:
This indicator is invaluable for traders employing carry trading strategies or assessing currency strength based on traded interest rates as an indicator. A higher yield spread typically indicates a stronger currency, because the return obtained for holding the currency is higher.
Originality and Practicality:
This script is self-developed, aiming to fill the gap in automatic bond yield comparisons within the TradingView environment. It is particularly beneficial for traders focusing on macroeconomic factors affecting forex markets. Unlike other scripts, it integrates various bond maturities into one tool, enhancing its utility and application range.
Conclusion:
Designed for traders incorporating macroeconomics in their strategy, this script will be useful to calculate the bond yield differences automatically without having to enter a new formula for every new currency pair.
Compliance and Limitations:
The script complies with TradingView scripting standards, ensuring no lookahead bias and maintaining real-time data integrity. However, its utility depends on the comprehensive availability of bond yield data within TradingView. As not all countries issue bonds for each listed maturity, this may limit the script’s application for certain currency pairs or specific maturities.
Backtesting ModuleDo you often find yourself creating new 'strategy()' scripts for each trading system? Are you unable to focus on generating new systems due to fatigue and time loss incurred in the process? Here's a potential solution: the 'Backtesting Module' :)
INTRODUCTION
Every trading system is based on four basic conditions: long entry, long exit, short entry and short exit (which are typically defined as boolean series in Pine Script).
If you can define the conditions generated by your trading system as a series of integers, it becomes possible to use these variables in different scripts in efficient ways. (Pine Script is a convenient language that allows you to use the integer output of one indicator as a source in another.)
The 'Backtesting Module' is a dynamic strategy script designed to adapt to your signals. It boasts two notable features:
⮞ It produces a backtest report using the entry and exit variables you define.
⮞ It not only serves for system testing but also to combine independent signals into a single system. (This functionality enables to create complex strategies and report on their success!)
The module tests Golden and Death cross signals by default, when you enter your own conditions the default signals will be neutralized. The methodology is described below.
PREPARATION
There are three simple steps to connect your own indicator to the Module.
STEP 1
Firstly, you must define entry and exit variables in your own script. Let's elucidate it with a straightforward example. Consider a system generating long and short signals based on the intersections of two moving averages. Consequently, our conditions would be as follows:
// Signals
long = ta.crossover(ta.sma(close, 14), ta.sma(close, 28))
short = ta.crossunder(ta.sma(close, 14), ta.sma(close, 28))
Now, the question is: How can we convert boolean variables into integer variables? The answer is conditional ternary block, defined as follows:
// Entry & Exit
long_entry = long ? 1 : 0
long_exit = short ? 1 : 0
short_entry = short ? 1 : 0
short_exit = long ? 1 : 0
The mechanics of the Entry & Exit variables are simple. The variable takes on a value of 1 when your trading system generates the signal and if your system does not produce any signal, variable returns 0. In this example, you see how exit signals can be generated in a trading system that only contains entry signals. If you have a system with original exit signals, you can also use them directly. (Please mind the NOTES section below).
STEP 2
To utilize the Entry & Exit variables as source in another script, they must be plotted on the chart. Therefore, the final detail to include in the script containing your trading system would be as follows:
// Plot The Output
plot(long_entry, "Long Entry", display=display.data_window, editable=false)
plot(long_exit, "Long Exit", display=display.data_window, editable=false)
plot(short_entry, "Short Entry", display=display.data_window, editable=false)
plot(short_exit, "Short Exit", display=display.data_window, editable=false)
STEP 3
Now, we are ready to test the system! Load the Backtesting Module indicator onto the chart along with your trading system/indicator. Then set the outputs of your system (Long Entry, Long Exit, Short Entry, Short Exit) as source in the module. That's it.
FEATURES & ORIGINALITY
⮞ Primarily, this script has been created to provide you with an easy and practical method when testing your trading system.
⮞ I thought it might be nice to visualize a few useful results. The Backtesting Module provides insights into the outcomes of both long and short trades by computing the number of trades and the success percentage.
⮞ Through the 'Trade' parameter, users can specify the market direction in which the indicator is permitted to initiate positions.
⮞ Users have the flexibility to define the date range for the test.
⮞ There are optional features allowing users to plot entry prices on the chart and customize bar colors.
⮞ The report and the test date range are presented in a table on the chart screen. The entry price can be monitored in the data window.
⮞ Note that results are based on realized returns, and the open trade is not included in the displayed results. (The only exception is the 'Unrealized PNL' result in the table.)
STRATEGY SETTINGS
The default parameters are as follows:
⮞ Initial Balance : 10000 (in units of currency)
⮞ Quantity : 10% of equity
⮞ Commission : 0.04%
⮞ Slippage : 0
⮞ Dataset : All bars in the chart
For a realistic backtest result, you should size trades to only risk sustainable amounts of equity. Do not risk more than 5-10% on a trade. And ALWAYS configure your commission and slippage parameters according to pessimistic scenarios!
NOTES
⮞ This script is intended solely for development purposes. And it'll will be available for all the indicators I publish.
⮞ In this version of the module, all order types are designed as market orders. The exit size is the sum of the entry size.
⮞ As your trading conditions grow more intricate, you might need to define the outputs of your system in alternative ways. The method outlined in this description is tailored for straightforward signal structures.
⮞ Additionally, depending on the structure of your trading system, the backtest module may require further development. This encompasses stop-loss, take-profit, specific exit orders, quantity, margin and risk management calculations. I am considering releasing improvements that consider these options in future versions.
⮞ An example of how complex trading signals can be generated is the OTT Collection. If you're interested in seeing how the signals are constructed, you can use the link below.
THANKS
Special thanks to PineCoders for their valuable moderation efforts.
I hope this will be a useful example for the TradingView community...
DISCLAIMER
This is just an indicator, nothing more. It is provided for informational and educational purposes exclusively. The utilization of this script does not constitute professional or financial advice. The user solely bears the responsibility for risks associated with script usage. Do not forget to manage your risk. And trade as safely as possible. Best of luck!
Rolling VWAP█ OVERVIEW
This indicator displays a Rolling Volume-Weighted Average Price. Contrary to VWAP indicators which reset at the beginning of a new time segment, RVWAP calculates using a moving window defined by a time period (not a simple number of bars), so it never resets.
█ CONCEPTS
If you are not already familiar with VWAP, our Help Center will get you started.
The typical VWAP is designed to be used on intraday charts, as it resets at the beginning of the day. Such VWAPs cannot be used on daily, weekly or monthly charts. Instead, this rolling VWAP uses a time period that automatically adjusts to the chart's timeframe. You can thus use RVWAP on any chart that includes volume information in its data feed.
Because RVWAP uses a moving window, it does not exhibit the jumpiness of VWAP plots that reset. You can see the more jagged VWAP on the chart above. We think both can be useful to traders; up to you to decide which flavor works for you.
█ HOW TO USE IT
Load the indicator on an active chart (see the Help Center if you don't know how).
Time period
By default, the script uses an auto-stepping mechanism to adjust the time period of its moving window to the chart's timeframe. The following table shows chart timeframes and the corresponding time period used by the script. When the chart's timeframe is less than or equal to the timeframe in the first column, the second column's time period is used to calculate RVWAP:
Chart Time
timeframe period
1min 🠆 1H
5min 🠆 4H
1H 🠆 1D
4H 🠆 3D
12H 🠆 1W
1D 🠆 1M
1W 🠆 3M
You can use the script's inputs to specify a fixed time period, which you can express in any combination of days, hours and minutes.
By default, the time period currently used is displayed in the lower-right corner of the chart. The script's inputs allow you to hide the display or change its size and location.
Minimum Window Size
This input field determines the minimum number of values to keep in the moving window, even if these values are outside the prescribed time period. This mitigates situations where a large time gap between two bars would cause the time window to be empty, which can occur in non-24x7 markets where large time gaps may separate contiguous chart bars, namely across holidays or trading sessions. For example, if you were using a 1D time period and there is a two-day gap between two bars, then no chart bars would fit in the moving window after the gap. The default value is 10 bars.
█ NOTES
If you are interested in VWAP indicators, you may find the VWAP Auto Anchored built-in indicator worth a try.
For Pine Script™ coders
The heart of this script's calculations uses the `totalForTimeWhen()` function from the ConditionalAverages library published by PineCoders . It works by maintaining an array of values included in a time period, but without a for loop requiring a lookback from the current bar, so it is much more efficient.
We write our Pine Script™ code using the recommendations in the User Manual's Style Guide .
Look first. Then leap.
Volume Spike Retracement█ OVERVIEW
-Following many people's request to add "Volume" mode again in my "Institutional OrderBlock Pressure" script. I decided to release an improved
and full-fledged script. This will be the last OB/Retracement script I will release as we have explored every possible way to find them.
█ HOW TO INTERPRET?
-The script uses the the 0.5 Pivot and the maximum value set for Volume Length to find 'Peak Volume'. Once these conditions are met,
the script starts creating a Retracement Line.
-By default, the Volume Length value is set to 89, which works well with most Timeframes following the OrderBlocks/Retracements
logic used in my scripts.
-You have the option to set Alerts when the "Volume Spike Limit" is reached or when a Price Crossing with a Line occurs.
█ NOTES
- Yes Alerts appear instantly. Moreover, they are not 'confirmed', you must ALWAYS wait for confirmation before making a choice.
Good Trade everyone and remember, risk management remains the most important!
Pinescript - Common Label & Line Array Functions Library by RRBPinescript - Common Label & Line Array Functions Library by RagingRocketBull 2021
Version 1.0
This script provides a library of common array functions for arrays of label and line objects with live testing of all functions.
Using this library you can easily create, update, delete, join label/line object arrays, and get/set properties of individual label/line object array items.
You can find the full list of supported label/line array functions below.
There are several libraries:
- Common String Functions Library
- Standard Array Functions Library
- Common Fixed Type Array Functions Library
- Common Label & Line Array Functions Library
- Common Variable Type Array Functions Library
Features:
- 30 array functions in categories create/update/delete/join/get/set with support for both label/line objects (45+ including all implementations)
- Create, Update label/line object arrays from list/array params
- GET/SET properties of individual label/line array items by index
- Join label/line objects/arrays into a single string for output
- Supports User Input of x,y coords of 5 different types: abs/rel/rel%/inc/inc% list/array, auto transforms x,y input into list/array based on type, base and xloc, translates rel into abs bar indexes
- Supports User Input of lists with shortened names of string properties, auto expands all standard string properties to their full names for use in functions
- Live Output for all/selected functions based on User Input. Test any function for possible errors you may encounter before using in script.
- Output filters: hide all excluded and show only allowed functions using a list of function names
- Output Panel customization options: set custom style, color, text size, and line spacing
Usage:
- select create function - create label/line arrays from lists or arrays (optional). Doesn't affect the update functions. The only change in output should be function name regardless of the selected implementation.
- specify num_objects for both label/line arrays (default is 7)
- specify common anchor point settings x,y base/type for both label/line arrays and GET/SET items in Common Settings
- fill lists with items to use as inputs for create label/line array functions in Create Label/Line Arrays section
- specify label/line array item index and properties to SET in corresponding sections
- select label/line SET function to see the changes applied live
Code Structure:
- translate x,y depending on x,y type, base and xloc as specified in UI (required for all functions)
- expand all shortened standard property names to full names (required for create/update* from arrays and set* functions, not needed for create/update* from lists) to prevent errors in label.new and line.new
- create param arrays from string lists (required for create/update* from arrays and set* functions, not needed for create/update* from lists)
- create label/line array from string lists (property names are auto expanded) or param arrays (requires already expanded properties)
- update entire label/line array or
- get/set label/line array item properties by index
Transforming/Expanding Input values:
- for this script to work on any chart regardless of price/scale, all x*,y* are specified as % increase relative to x0,y0 base levels by default, but user can enter abs x,price values specific for that chart if necessary.
- all lists can be empty, contain 1 or several items, have the same/different lengths. Array Length = min(min(len(list*)), mum_objects) is used to create label/line objects. Missing list items are replaced with default property values.
- when a list contains only 1 item it is duplicated (label name/tooltip is also auto incremented) to match the calculated Array Length
- since this script processes user input, all x,y values must be translated to abs bar indexes before passing them to functions. Your script may provide all data internally and doesn't require this step.
- at first int x, float y arrays are created from user string lists, transformed as described below and returned as x,y arrays.
- translated x,y arrays can then be passed to create from arrays function or can be converted back to x,y string lists for the create from lists function if necessary.
- all translation logic is separated from create/update/set functions for the following reasons:
- to avoid redundant code/dependency on ext functions/reduce local scopes and to be able to translate everything only once in one place - should be faster
- to simplify internal logic of all functions
- because your script may provide all data internally without user input and won't need the translation step
- there are 5 types available for both x,y: abs, rel, rel%, inc, inc%. In addition to that, x can be: bar index or time, y is always price.
- abs - absolute bar index/time from start bar0 (x) or price (y) from 0, is >= 0
- rel - relative bar index/time from cur bar n (x) or price from y0 base level, is >= 0
- rel% - relative % increase of bar index/time (x) or price (y) from corresponding base level (x0 or y0), can be <=> 0
- inc - relative increment (step) for each new level of bar index/time (x) or price (y) from corresponding base level (x0 or y0), can be <=> 0
- inc% - relative % increment (% step) for each new level of bar index/time (x) or price (y) from corresponding base level (x0 or y0), can be <=> 0
- x base level >= 0
- y base level can be 0 (empty) or open, close, high, low of cur bar
- single item x1_list = "50" translates into:
- for x type abs: "50, 50, 50 ..." num_objects times regardless of xloc => x = 50
- for x type rel: "50, 50, 50 ... " num_objects times => x = x_base + 50
- for x type rel%: "50%, 50%, 50% ... " num_objects times => x_base * (1 + 0.5)
- for x type inc: "0, 50, 100 ... " num_objects times => x_base + 50 * i
- for x type inc%: "0%, 50%, 100% ... " num_objects times => x_base * (1 + 0.5 * i)
- when xloc = xloc.bar_index each rel*/inc* value in the above list is then subtracted from n: n - x to convert rel to abs bar index, values of abs type are not affected
- x1_list = "0, 50, 100, ..." of type rel is the same as "50" of type inc
- x1_list = "50, 50, 50, ..." of type abs/rel/rel% produces a sequence of the same values and can be shortened to just "50"
- single item y1_list = "2" translates into (ragardless of yloc):
- for y type abs: "2, 2, 2 ..." num_objects times => y = 2
- for y type rel: "2, 2, 2 ... " num_objects times => y = y_base + 2
- for y type rel%: "2%, 2%, 2% ... " num_objects times => y = y_base * (1 + 0.02)
- for y type inc: "0, 2, 4 ... " num_objects times => y = y_base + 2 * i
- for y type inc%: "0%, 2%, 4% ... " num_objects times => y = y_base * (1 + 0.02 * i)
- when yloc != yloc.price all calculated values above are simply ignored
- y1_list = "0, 2, 4" of type rel% is the same as "2" with type inc%
- y1_list = "2, 2, 2" of type abs/rel/rel% produces a sequence of the same values and can be shortened to just "2"
- you can enter shortened property names in lists. To lookup supported shortened names use corresponding dropdowns in Set Label/Line Array Item Properties sections
- all shortened standard property names must be expanded to full names (required for create/update* from arrays and set* functions, not needed for create/update* from lists) to prevent errors in label.new and line.new
- examples of shortened property names that can be used in lists: bar_index, large, solid, label_right, white, left, left, price
- expanded to their corresponding full names: xloc.bar_index, size.large, line.style_solid, label.style_label_right, color.white, text.align_left, extend.left, yloc.price
- all expanding logic is separated from create/update* from arrays and set* functions for the same reasons as above, and because param arrays already have different types, implying the use of final values.
- all expanding logic is included in the create/update* from lists functions because it seemed more natural to process string lists from user input directly inside the function, since they are already strings.
Creating Label/Line Objects:
- use study max_lines_count and max_labels_count params to increase the max number of label/line objects to 500 (+3) if necessary. Default number of label/line objects is 50 (+3)
- all functions use standard param sequence from methods in reference, except style always comes before colors.
- standard label/line.get* functions only return a few properties, you can't read style, color, width etc.
- label.new(na, na, "") will still create a label with x = n-301, y = NaN, text = "" because max default scope for a var is 300 bars back.
- there are 2 types of color na, label color requires color(na) instead of color_na to prevent error. text_color and line_color can be color_na
- for line to be visible both x1, x2 ends must be visible on screen, also when y1 == y2 => abs(x1 - x2) >= 2 bars => line is visible
- xloc.bar_index line uses abs x1, x2 indexes and can only be within 0 and n ends, where n <= 5000 bars (free accounts) or 10000 bars (paid accounts) limit, can't be plotted into the future
- xloc.bar_time line uses abs x1, x2 times, can't go past bar0 time but can continue past cur bar time into the future, doesn't have a length limit in bars.
- xloc.bar_time line with length = exact number of bars can be plotted only within bar0 and cur bar, can't be plotted into the future reliably because of future gaps due to sessions on some charts
- xloc.bar_index line can't be created on bar 0 with fixed length value because there's only 1 bar of horiz length
- it can be created on cur bar using fixed length x < n <= 5000 or
- created on bar0 using na and then assigned final x* values on cur bar using set_x*
- created on bar0 using n - fixed_length x and then updated on cur bar using set_x*, where n <= 5000
- default orientation of lines (for style_arrow* and extend) is from left to right (from bar 50 to bar 0), it reverses when x1 and x2 are swapped
- price is a function, not a line object property
Variable Type Arrays:
- you can't create an if/function that returns var type value/array - compiler uses strict types and doesn't allow that
- however you can assign array of any type to another array of any type creating an arr pointer of invalid type that must be reassigned to a matching array type before used in any expression to prevent error
- create_any_array2 uses this loophole to return an int_arr pointer of a var type array
- this works for all array types defined with/without var keyword and doesn't work for string arrays defined with var keyword for some reason
- you can't do this with var type vars, only var type arrays because arrays are pointers passed by reference, while vars are actual values passed by value.
- you can only pass a var type value/array param to a function if all functions inside support every type - otherwise error
- alternatively values of every type must be passed simultaneously and processed separately by corresponding if branches/functions supporting these particular types returning a common single type result
- get_var_types solves this problem by generating a list of dummy values of every possible type including the source type, tricking the compiler into allowing a single valid branch to execute without error, while ignoring all dummy results
Notes:
- uses Pinescript v3 Compatibility Framework
- uses Common String Functions Library, Common Fixed Type Array Functions Library, Common Variable Type Array Functions Library
- has to be a separate script to reduce the number of local scopes/compiled file size, can't be merged with another library.
- lets you live test all label/line array functions for errors. If you see an error - change params in UI
- if you see "Loop too long" error - hide/unhide or reattach the script
- if you see "Chart references too many candles" error - change x type or value between abs/rel*. This can happen on charts with 5000+ bars when a rel bar index x is passed to label.new or line.new instead of abs bar index n - x
- create/update_label/line_array* use string lists, while create/update_label/line_array_from_arrays* use array params to create label/line arrays. "from_lists" is dropped to shorten the names of the most commonly used functions.
- create_label/line_array2,4 are preferable, 5,6 are listed for pure demonstration purposes only - don't use them, they don't improve anything but dramatically increase local scopes/compiled file size
- for this reason you would mainly be using create/update_label/line_array2,4 for list params or create/update_label/line_array_from_arrays2 for array params
- all update functions are executed after each create as proof of work and can be disabled. Only create functions are required. Use update functions when necessary - when list/array params are changed by your script.
- both lists and array item properties use the same x,y_type, x,y_base from common settings
- doesn't use pagination, a single str contains all output
- why is this so complicated? What are all these functions for?
- this script merges standard label/line object methods with standard array functions to create a powerful set of label/line object array functions to simplify manipulation of these arrays.
- this library also extends the functionality of Common Variable Type Array Functions Library providing support for label/line types in var type array functions (any_to_str6, join_any_array5)
- creating arrays from either lists or arrays adds a level of flexibility that comes with complexity. It's very likely that in your script you'd have to deal with both string lists as input, and arrays internally, once everything is converted.
- processing user input, allowing customization and targeting for any chart adds a whole new layer of complexity, all inputs must be translated and expanded before used in functions.
- different function implementations can increase/reduce local scopes and compiled file size. Select a version that best suits your needs. Creating complex scripts often requires rewriting your code multiple times to fit the limits, every line matters.
P.S. Don't rely too much on labels, for too often they are fables.
List of functions*:
* - functions from other libraries are not listed
1. Join Functions
Labels
- join_label_object(label_, d1, d2)
- join_label_array(arr, d1, d2)
- join_label_array2(arr, d1, d2, d3)
Lines
- join_line_object(line_, d1, d2)
- join_line_array(arr, d1, d2)
- join_line_array2(arr, d1, d2, d3)
Any Type
- any_to_str6(arr, index, type)
- join_any_array4(arr, d1, d2, type)
- join_any_array5(arr, d, type)
2. GET/SET Functions
Labels
- label_array_get_text(arr, index)
- label_array_get_xy(arr, index)
- label_array_get_fields(arr, index)
- label_array_set_text(arr, index, str)
- label_array_set_xy(arr, index, x, y)
- label_array_set_fields(arr, index, x, y, str)
- label_array_set_all_fields(arr, index, x, y, str, xloc, yloc, label_style, label_color, text_color, text_size, text_align, tooltip)
- label_array_set_all_fields2(arr, index, x, y, str, xloc, yloc, label_style, label_color, text_color, text_size, text_align, tooltip)
Lines
- line_array_get_price(arr, index, bar)
- line_array_get_xy(arr, index)
- line_array_get_fields(arr, index)
- line_array_set_text(arr, index, width)
- line_array_set_xy(arr, index, x1, y1, x2, y2)
- line_array_set_fields(arr, index, x1, y1, x2, y2, width)
- line_array_set_all_fields(arr, index, x1, y1, x2, y2, xloc, extend, line_style, line_color, width)
- line_array_set_all_fields2(arr, index, x1, y1, x2, y2, xloc, extend, line_style, line_color, width)
3. Create/Update/Delete Functions
Labels
- delete_label_array(label_arr)
- create_label_array(list1, list2, list3, list4, list5, d)
- create_label_array2(x_list, y_list, str_list, xloc_list, yloc_list, style_list, color1_list, color2_list, size_list, align_list, tooltip_list, d)
- create_label_array3(x_list, y_list, str_list, xloc_list, yloc_list, style_list, color1_list, color2_list, size_list, align_list, tooltip_list, d)
- create_label_array4(x_list, y_list, str_list, xloc_list, yloc_list, style_list, color1_list, color2_list, size_list, align_list, tooltip_list, d)
- create_label_array5(x_list, y_list, str_list, xloc_list, yloc_list, style_list, color1_list, color2_list, size_list, align_list, tooltip_list, d)
- create_label_array6(x_list, y_list, str_list, xloc_list, yloc_list, style_list, color1_list, color2_list, size_list, align_list, tooltip_list, d)
- update_label_array2(label_arr, x_list, y_list, str_list, xloc_list, yloc_list, style_list, color1_list, color2_list, size_list, align_list, tooltip_list, d)
- update_label_array4(label_arr, x_list, y_list, str_list, xloc_list, yloc_list, style_list, color1_list, color2_list, size_list, align_list, tooltip_list, d)
- create_label_array_from_arrays2(x_arr, y_arr, str_arr, xloc_arr, yloc_arr, style_arr, color1_arr, color2_arr, size_arr, align_arr, tooltip_arr, d)
- create_label_array_from_arrays4(x_arr, y_arr, str_arr, xloc_arr, yloc_arr, style_arr, color1_arr, color2_arr, size_arr, align_arr, tooltip_arr, d)
- update_label_array_from_arrays2(label_arr, x_arr, y_arr, str_arr, xloc_arr, yloc_arr, style_arr, color1_arr, color2_arr, size_arr, align_arr, tooltip_arr, d)
Lines
- delete_line_array(line_arr)
- create_line_array(list1, list2, list3, list4, list5, list6, d)
- create_line_array2(x1_list, y1_list, x2_list, y2_list, xloc_list, extend_list, style_list, color_list, width_list, d)
- create_line_array3(x1_list, y1_list, x2_list, y2_list, xloc_list, extend_list, style_list, color_list, width_list, d)
- create_line_array4(x1_list, y1_list, x2_list, y2_list, xloc_list, extend_list, style_list, color_list, width_list, d)
- create_line_array5(x1_list, y1_list, x2_list, y2_list, xloc_list, extend_list, style_list, color_list, width_list, d)
- create_line_array6(x1_list, y1_list, x2_list, y2_list, xloc_list, extend_list, style_list, color_list, width_list, d)
- update_line_array2(line_arr, x1_list, y1_list, x2_list, y2_list, xloc_list, extend_list, style_list, color_list, width_list, d)
- update_line_array4(line_arr, x1_list, y1_list, x2_list, y2_list, xloc_list, extend_list, style_list, color_list, width_list, d)
- create_line_array_from_arrays2(x1_arr, y1_arr, x2_arr, y2_arr, xloc_arr, extend_arr, style_arr, color_arr, width_arr, d)
- update_line_array_from_arrays2(line_arr, x1_arr, y1_arr, x2_arr, y2_arr, xloc_arr, extend_arr, style_arr, color_arr, width_arr, d)
